Web sitesinde güvenlik başlıkları nasıl eklenir?

Web sitesinde güvenlik başlıkları, sunucu veya uygulama yapılandırmasına HTTP yanıt başlıkları eklenerek kurulur. En sık kullanılan başlıklar Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options ve Referrer-Policy’dir. Bu başlıklar HTTPS sertifikasının yerine geçmez. HTTPS bağlantıyı şifrelerken güvenlik başlıkları, tarayıcının içerikleri nasıl yükleyeceğini ve dış kaynaklarla nasıl iletişim kuracağını belirler.

Kurulumdan önce sitenin hangi sunucuyu kullandığı belirlenmelidir. Apache, Nginx, Microsoft IIS, Cloudflare veya bir içerik yönetim sistemi farklı ayar dosyaları kullanır. Yanlış dosyaya eklenen başlık tarayıcıya hiç ulaşmaz. Bu nedenle önce mevcut yanıtlar incelenmeli, ardından tek bir başlık değiştirilmeli ve tekrar test edilmelidir.

Web sitesinde güvenlik başlıkları neden eklenir?

Web sitesinde güvenlik başlıkları, tarayıcının riskli içerik ve bağlantı davranışlarını sınırlandırmak için eklenir. Tarayıcı varsayılanları bazı saldırı türlerini azaltabilir. Ancak varsayılan davranış, sitenin hangi kaynaklara güvenmesi gerektiğini her zaman bilmez.

Content-Security-Policy, JavaScript, stil dosyası, görsel, yazı tipi ve iframe kaynaklarını sınırlandırır. Bu sınırlama, bir saldırganın sayfaya eklediği yetkisiz betiğin çalışmasını zorlaştırır. Politika hatalı yazılırsa ödeme ekranı, analiz kodu veya canlı destek bileşeni çalışmayabilir.

HSTS, tarayıcıya sitenin belirli bir süre yalnızca HTTPS üzerinden açılmasını söyler. X-Content-Type-Options, tarayıcının dosya türünü tahmin ederek farklı yorumlamasını engeller. Referrer-Policy ise başka sayfalara gönderilen yönlendiren URL bilgisini sınırlar.

Bu başlıklar tek başına güvenli bir uygulama oluşturmaz. Güncel yazılım, güçlü yönetici parolası, erişim yetkileri, yedekleme, güvenli çerez ayarları ve sunucu güncellemeleri ayrıca kontrol edilmelidir. Başlıklar, bu kontrollerin tarayıcı tarafındaki tamamlayıcısıdır.

Örneğin CSP, veritabanı açığını düzeltmez. HSTS, ele geçirilmiş yönetici hesabını korumaz. Referrer-Policy de sunucudaki dosya izinlerini değiştirmez. Bu nedenle güvenlik başlıkları, kapsamı belirli teknik önlemler olarak değerlendirilmelidir.

Performans çalışmalarıyla güvenlik ayarları da birlikte izlenmelidir. Bazı CSP değişiklikleri üçüncü taraf betiklerini kesebilir veya sayfa düzeninin geç oluşmasına neden olabilir. Bu durumda web sitesinde CLS kayması nasıl düzeltilir rehberindeki ölçüm yaklaşımı kullanılabilir.

Hangi güvenlik başlıkları önce eklenmelidir?

Öncelik sırası, sitenin altyapısı ve üçüncü taraf kaynakları incelenerek belirlenmelidir. Tüm başlıkları aynı anda değiştirmek yerine, etkisi düşük başlıklardan başlayıp CSP’yi kontrollü kurmak daha güvenlidir.

İlk aşamada X-Content-Type-Options: nosniff eklenebilir. Bu başlık genellikle tek satırlıdır ve tarayıcının Content-Type değerini tahmin etmesini sınırlar. Sunucunun doğru MIME türlerini göndermediği eski sitelerde önce dosya yanıtları kontrol edilmelidir.

İkinci aşamada Referrer-Policy: strict-origin-when-cross-origin kullanılabilir. Bu politika, aynı kaynak içindeki yönlendirmelerde daha fazla bilgi bırakırken farklı alan adlarına geçişte tam URL yerine kaynak bilgisini gönderir. Hassas URL parametreleri taşıyan sayfalarda daha sıkı seçenek gerekebilir.

HSTS, HTTPS’in tüm sayfalarda ve alt kaynaklarda sorunsuz çalıştığı doğrulandıktan sonra eklenmelidir. Sertifika süresi, www ve kök alan adı yönlendirmeleri, alt alan adları ve HTTP’den HTTPS’e geçiş ayrıca test edilmelidir.

CSP en son ve raporlama modunda başlanarak uygulanmalıdır. Content-Security-Policy-Report-Only başlığı, ihlalleri bildirir fakat içeriği engellemez. Böylece ödeme, form, analiz ve medya servislerinin hangi kaynaklara ihtiyaç duyduğu görülür.

Yanlış: CSP’ye baştan sona yıldız karakteri ekleyip güvenliği tamamlanmış saymak. Doğru: Önce kullanılan kaynakları listelemek, raporlama modunda ihlalleri izlemek ve yalnızca gerekli alan adlarına izin vermek.

Bu sıra, her site için değişmez bir kural değildir. Sıkı uyumluluk gerektiren projelerde güvenlik ekibi farklı bir plan uygulayabilir. Önemli olan, her değişiklikten sonra gerçek kullanıcı akışlarının test edilmesidir.

Content-Security-Policy nasıl eklenir?

Content-Security-Policy, HTTP yanıtına politika tanımlayan bir başlık eklenerek kurulur. Politika, tarayıcıya hangi kaynak türlerinin hangi adreslerden yüklenebileceğini söyler.

Basit bir başlangıç politikası şu biçimde olabilir: default-src 'self'; img-src 'self' https: data:; style-src 'self' 'unsafe-inline'; script-src 'self'; font-src 'self' data:; object-src 'none'; base-uri 'self'; frame-ancestors 'self'. Bu örnek doğrudan her siteye uygulanmamalıdır.

Analiz, reklam, ödeme, harita veya canlı destek kodları kullanılan sitelerde ilgili alan adları ayrıca tanımlanır. Ancak her üçüncü taraf alan adını eklemek politikayı genişletir. Kaynağın gerçekten gerekli olup olmadığı, tarayıcı geliştirici araçları ve raporlar üzerinden kontrol edilmelidir.

Inline script kullanan sitelerde nonce veya hash yaklaşımı daha güvenlidir. Nonce, her yanıt için üretilen tahmin edilmesi zor bir değerdir. Sunucu bu değeri CSP içinde ve izin verilen script etiketinde aynı şekilde kullanır.

CSP kurulurken unsafe-eval ve geniş kapsamlı wildcard kullanımı dikkatle değerlendirilmelidir. Bu ifadeler bazı eski kütüphaneleri çalıştırabilir. Fakat izin verilen kod alanını büyütür. Önce kütüphane güncellenmeli, ardından bu istisnaların kaldırılması denenmelidir.

Kurulumdan sonra tarayıcı konsolu, raporlama servisi ve kritik sayfa akışları birlikte izlenir. Ana sayfa, iletişim formu, kullanıcı girişi, sepet, ödeme ve yönetim paneli ayrı ayrı test edilmelidir.

CSP, XSS riskini azaltır ancak uygulamadaki çıktı kodlama hatalarını ortadan kaldırmaz. Kullanıcı verisi HTML’e güvenli biçimde yazılmıyorsa uygulama kodu yine düzeltilmelidir. Başlık, yazılım güvenliğinin yerine geçen bir filtre değildir.

HSTS başlığı nasıl etkinleştirilir?

HSTS, Strict-Transport-Security başlığıyla etkinleştirilir ve yalnızca HTTPS üzerinden çalışan sitelerde kullanılmalıdır. Örnek değer şu şekildedir: max-age=31536000; includeSubDomains.

max-age değeri, tarayıcının HTTPS zorlamasını saniye cinsinden belirler. İlk kurulumda daha kısa bir test süresi seçilebilir. Tüm alt alan adlarının HTTPS’e hazır olduğu doğrulandıktan sonra daha uzun bir süreye geçilmelidir.

includeSubDomains kullanıldığında alt alan adları da HTTPS zorlamasına girer. Kullanılmayan, eski veya farklı ekip tarafından yönetilen bir alt alan adı varsa bu seçenek sorun çıkarabilir. Özellikle mail, panel, test ve dosya alt alan adları tek tek kontrol edilmelidir.

HSTS, HTTP bağlantısını otomatik olarak HTTPS’e dönüştürür. Ancak ilk ziyaret öncesinde sertifika hatasını çözmez. Kullanıcı yanlış sertifikaya sahip bir adrese giderse HSTS bu bağlantıyı güvenli hale getirmez; bağlantıyı reddeder.

HSTS preload listesine girme, ayrı bir karar olarak ele alınmalıdır. Bu listeler tarayıcıların siteye ilk bağlantıdan önce de HTTPS kullanmasını sağlar. Fakat listeden çıkış hızlı gerçekleşmez. Bu nedenle alan adındaki tüm alt alan adları ve yönlendirmeler uzun vadeli olarak kontrol edilmelidir.

Test sırasında şu adresler izlenmelidir: http://alanadiniz.com, http://www.alanadiniz.com, https://alanadiniz.com ve varsa alt alan adları. Her HTTP varyasyonunun doğru HTTPS adresine yönlendiği, sertifikanın geçerli olduğu ve karma içerik bulunmadığı doğrulanmalıdır.

HSTS, yönetim paneli veya ödeme ekranı için ayrı bir başlık değildir. Aynı alan adından sunulan tüm yanıtları etkiler. Bu nedenle sadece tek bir sayfada değil, sunucu seviyesinde tutarlı biçimde gönderilmesi gerekir.

X-Content-Type-Options ve Referrer-Policy nasıl ayarlanır?

X-Content-Type-Options başlığı nosniff değeriyle ayarlanır ve tarayıcının Content-Type bilgisini tahmin ederek farklı bir dosya türü kullanmasını sınırlar. Kurulum satırı şöyledir: X-Content-Type-Options: nosniff.

Bu başlık özellikle JavaScript ve stil dosyalarında doğru MIME türü gönderilmesini gerektirir. JavaScript dosyaları için text/javascript, CSS dosyaları için text/css gibi uygun yanıt türleri kullanılmalıdır. Hatalı sunucu yapılandırması, nosniff sonrasında dosyanın engellenmesine yol açabilir.

Referrer-Policy, ziyaretçinin başka bir sayfaya geçerken hangi kaynak URL bilgisini göndereceğini belirler. strict-origin-when-cross-origin, farklı alan adlarına geçişte yol ve sorgu parametrelerini paylaşmaz. Bu ayar, birçok kurumsal site için dengeli bir başlangıç seçeneğidir.

Parola sıfırlama, davet, sipariş veya kişisel bilgi içeren URL’lerde daha sıkı politika gerekebilir. no-referrer seçeneği yönlendiren bilgiyi tamamen kaldırır. Ancak bazı analiz süreçleri kaynak bilgisini kullandığından, iş gereksinimiyle birlikte değerlendirme yapılmalıdır.

Bu iki başlık, Content-Security-Policy kadar geniş uygulama etkisi yaratmayabilir. Yine de eski dosya türleri, üçüncü taraf formlar ve kampanya takip parametreleri incelenmeden rastgele eklenmemelidir.

Aşağıdaki karşılaştırma temel tercihleri özetler:

Apache ve Nginx sunucularında güvenlik başlıkları nasıl eklenir?

Apache ve Nginx sunucularında güvenlik başlıkları, yapılandırma dosyasına eklenen yanıt kurallarıyla gönderilir. Dosyanın konumu ve yetkisi hosting sağlayıcısına göre değişir.

Apache için mod_headers etkinse .htaccess veya sanal host yapılandırmasında şu kurallar kullanılabilir: Header always set X-Content-Type-Options nosniff, Header always set Referrer-Policy strict-origin-when-cross-origin ve Header always set Strict-Transport-Security 'max-age=31536000; includeSubDomains'.

Apache’de Header always kullanımı, hata yanıtlarında da başlığın gönderilmesine yardımcı olur. Ancak bazı hosting paketlerinde bu modül kapalı olabilir. Değişiklikten sonra yapılandırma testi çalıştırılmadan Apache yeniden başlatılmamalıdır.

Nginx için add_header yönergesi kullanılır. Örnek yapılandırma şu biçimdedir: add_header X-Content-Type-Options nosniff always; add_header Referrer-Policy strict-origin-when-cross-origin always; add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains' always.

Nginx’te add_header kuralları iç içe location bloklarında beklenmedik biçimde uygulanabilir. Alt blokta başka add_header direktifleri varsa üst seviyedeki başlıklar görünmeyebilir. Bu nedenle yalnızca ana yapılandırmaya bakmak yerine gerçek HTTP yanıtı kontrol edilmelidir.

Cloudflare gibi bir CDN kullanılıyorsa başlıklar origin sunucuda, CDN kuralında veya uygulama katmanında eklenebilir. Aynı başlığın iki farklı yerde farklı değerlerle gönderilmesi tarayıcı davranışını karmaşıklaştırabilir.

1. Sunucunun Apache, Nginx, IIS veya CDN olduğunu belirleyin.
2. Mevcut yanıt başlıklarını curl veya tarayıcı ağı paneliyle kaydedin.
3. Tek bir başlık ekleyip yapılandırma sözdizimini test edin.
4. HTTP 200, 301, 404 ve 500 yanıtlarını ayrı ayrı inceleyin.
5. Mobil, masaüstü, giriş ve ödeme akışlarını tekrar çalıştırın.
6. Başlık değerlerini sürüm notuyla kaydedin ve geri dönüş planı oluşturun.

Sunucu erişimi olmayan sitelerde bu ayarlar hosting panelinden veya uygulama eklentisinden yapılabilir. Eklentinin hangi başlıkları eklediği önce doğrulanmalıdır. Aynı başlığın farklı eklentilerce tekrarlanması engellenmelidir.

Güvenlik başlıkları nasıl test edilir?

Güvenlik başlıkları, gerçek HTTP yanıtları incelenerek test edilir. Sadece kaynak kodunu veya tarayıcıdaki HTML çıktısını kontrol etmek yeterli değildir.

Komut satırında curl -I https://alanadiniz.com komutu kullanılabilir. Bu komut, sunucunun döndürdüğü başlıkları gösterir. Yönlendirme zincirini incelemek için -L seçeneği kullanılabilir; fakat son yanıtla ara yanıtlar ayrı değerlendirilmelidir.

Tarayıcının geliştirici araçlarında Network sekmesi açılır. Belirli bir HTML dokümanı seçilir ve Response Headers bölümü incelenir. CSS, JavaScript, görsel ve iframe yanıtlarında da Content-Type değerleri kontrol edilir.

CSP için önce Report-Only kullanılması yararlıdır. Konsol mesajları hangi kaynağın engellenme riski taşıdığını gösterir. Her rapor otomatik olarak izin gerekçesi sayılmamalıdır. Kullanılmayan veya şüpheli bir alan adı görülürse önce uygulama kodu incelenmelidir.

Güvenlik başlığı tarama araçları hızlı kontrol sağlar. Ancak araç puanı, sitenin iş mantığını ve ödeme akışını değerlendirmez. Bir araçta yüksek puan almak, CSP’nin doğru kapsamda olduğu anlamına gelmez.

Test listesinde ana sayfa dışında giriş, kayıt, arama, ürün detayı, sepet, ödeme, iletişim ve dosya indirme sayfaları bulunmalıdır. Kurumsal sitelerde teklif formu, bayi girişi ve yönetim paneli de ayrıca kontrol edilmelidir.

Değişiklikten sonra tarayıcı önbelleği ve CDN önbelleği dikkate alınmalıdır. Eski yanıtların görülmesi, ayarın çalışmadığı anlamına gelmeyebilir. Farklı bir ağdan veya önbellek temizlenmiş bir tarayıcıdan tekrar test yapılmalıdır.

Güvenlik testleri performans testlerinden ayrı yürütülmemelidir. Üçüncü taraf betiklerin yüklenme sırası değişirse LCP etkilenebilir. Bu durumda web sitesinde LCP skoru nasıl düşürülür içeriğindeki ölçüm mantığıyla önce ve sonra verisi karşılaştırılabilir.

E-ticaret sitelerinde güvenlik başlıkları nasıl uygulanır?

E-ticaret sitelerinde güvenlik başlıkları, ödeme ve kullanıcı hesabı akışları bozulmadan uygulanmalıdır. Ürün sayfası, sepet ve ödeme sayfası aynı güvenlik politikasına sahip olmayabilir.

Ödeme sağlayıcısının iframe, JavaScript veya yönlendirme gereksinimleri CSP içinde açıkça tanımlanmalıdır. İzin verilen alan adları sağlayıcının güncel teknik dokümanından alınmalıdır. Tahmini veya eski alan adlarıyla yazılan kurallar ödeme ekranında hata oluşturabilir.

Güvenlik başlıkları kart verisini sunucuda saklamaz ve PCI yükümlülüklerini ortadan kaldırmaz. Kart verisinin hangi servis tarafından işlendiği, token kullanımı, yönetici erişimleri ve loglarda hassas bilgi bulunup bulunmadığı ayrıca incelenmelidir.

HSTS, e-ticaret sitelerinde özellikle önemlidir. Ürün, sepet ve giriş sayfalarının HTTP üzerinden açılması engellenmelidir. Ancak ödeme sağlayıcısının alan adı site tarafından yönetilmiyorsa, HSTS yalnızca sitenin kendi alan adına uygulanır.

Referrer-Policy seçimi kampanya ölçümünü etkileyebilir. UTM parametreleri genellikle URL’de bulunur. Tam URL’nin dış kaynaklara gönderilmesi istenmiyorsa kaynak bilgisiyle yetinen politika kullanılmalıdır. Ölçüm kaybı, analiz panelinde önce ve sonra karşılaştırmasıyla izlenmelidir.

E-ticaret sayfalarında üçüncü taraf servis sayısı arttıkça CSP bakımı zorlaşır. Her yeni reklam pikseli, sohbet aracı veya öneri motoru politika değişikliği gerektirebilir. Bu değişiklikler doğrudan canlıya alınmadan önce test ortamında denenmelidir.

Ödeme sonrası dönüş URL’leri ve web kancaları da kontrol edilmelidir. Başlıklar tarayıcı davranışını etkiler, sunucudan sunucuya çalışan web kancalarını genellikle etkilemez. Yine de ödeme sağlayıcısının callback adresleri ve TLS ayarları ayrı test edilmelidir.

Erişilebilirlik açısından güvenlik başlıkları doğrudan yeterlilik sağlamaz. Klavye kullanımı, form etiketleri ve hata mesajları ayrıca incelenmelidir. Bu nedenle e-ticaret siteleri için erişilebilirlik zorunlu mu rehberindeki ayrı kontrol başlıkları da değerlendirilmelidir.

Güvenlik başlıkları eklenirken hangi hatalar yapılır?

En yaygın hata, başlıkları yalnızca ana sayfada test edip tüm sitenin güvenli olduğunu varsaymaktır. Yanıt başlıkları sunucu, uygulama rotası, CDN ve hata sayfasına göre farklılaşabilir.

İkinci hata, CSP içine her alan adını eklemektir. Bu yaklaşım kısa vadede hata mesajlarını azaltabilir. Fakat yetkisiz bir dış kaynağın yüklenmesine izin verebilir. Her kaynak için kullanım amacı, sahiplik ve gereklilik kaydı tutulmalıdır.

Üçüncü hata, HSTS’yi alt alan adlarını incelemeden etkinleştirmektir. Test sunucusu, eski webmail arayüzü veya dosya alanı HTTPS desteklemiyorsa includeSubDomains erişim sorununa neden olabilir.

Dördüncü hata, HTTP yanıtı yerine meta etiketi kullanmaktır. Bazı güvenlik politikaları meta etiketiyle sınırlı biçimde çalışabilir. HSTS gibi başlıklar ise HTTP yanıtında gönderilmelidir. Sunucu seviyesinde gönderim daha tutarlı sonuç verir.

Beşinci hata, başlıkların değerini kontrol etmeden güvenlik tarama puanına odaklanmaktır. Bir başlığın var olması, doğru yapılandırıldığı anlamına gelmez. Özellikle CSP’de kaynak kapsamı, nonce kullanımı ve iframe kuralları ayrıca incelenmelidir.

Altıncı hata, üçüncü taraf eklentiyi güncelledikten sonra CSP raporlarını izlememektir. Eklenti yeni bir alan adına veya inline koda ihtiyaç duyabilir. Bu değişiklik canlı sitede form veya ödeme hatası olarak ortaya çıkabilir.

• HTTPS tüm sayfalarda ve alt kaynaklarda çalışıyor mu?
• HTTP adresleri doğru HTTPS adresine yönleniyor mu?
• HSTS alt alan adları kontrol edildikten sonra mı açıldı?
• CSP önce Report-Only modunda izlendi mi?
• Ödeme, giriş ve form akışları test edildi mi?
• JavaScript ve CSS yanıtlarında doğru Content-Type gönderiliyor mu?
• Referrer-Policy kampanya ölçümünü etkiliyor mu?
• CDN ve origin sunucuda çakışan değer bulunuyor mu?

Güvenlik başlıkları ne zaman güncellenmelidir?

Güvenlik başlıkları, altyapı veya üçüncü taraf kaynak değiştiğinde güncellenmelidir. Takvim, sitenin yayın sıklığına göre belirlenmeli ve her değişiklik kayıt altına alınmalıdır.

Yeni analiz aracı, reklam pikseli, ödeme sağlayıcısı, video oynatıcı veya canlı destek sistemi eklendiğinde CSP yeniden incelenir. Kullanılmayan alan adları da düzenli olarak kaldırılır. Listeyi büyütmek yerine sadeleştirmek daha kontrollü bir yapı sağlar.

Alan adı değişikliği, CDN geçişi, sunucu taşıması veya yeni alt alan adı açılması HSTS için tetikleyici kabul edilmelidir. Sertifika yenileme süreci de otomatik izlenmelidir. HSTS, süresi dolmuş sertifikayı düzeltmez.

Aylık veya üç aylık kontrol planı uygulanabilir. Bu kontrolde HTTP yanıtları, CSP raporları, sertifika durumu, yönlendirmeler ve kritik formlar birlikte incelenir. Kesin aralık, sitenin güncelleme ve işlem hacmine göre seçilmelidir.

Başlık değişiklikleri için geri dönüş planı bulunmalıdır. CSP nedeniyle ödeme durursa önce son politika sürümüne dönülebilir. Ardından engellenen kaynağın gerçekten gerekli olup olmadığı test ortamında incelenir.

İçerik yönetim sistemi güncellendiğinde yalnızca görsel arayüz kontrol edilmemelidir. Yeni eklenti dosyaları, API istekleri ve yönetim paneli rotaları da taranmalıdır. Özellikle otomatik eklenen inline scriptler CSP ihlali oluşturabilir.

Performans ölçümleri de güncelleme kaydına eklenmelidir. Header değişikliği doğrudan hızlandırma sağlamaz. Ancak üçüncü taraf kaynakların kontrolsüz yüklenmesini sınırlayabilir. Değişiklik sonrasında LCP, CLS ve JavaScript hataları önceki ölçümle karşılaştırılmalıdır.

Yapay zekâ botlarının erişimi ise güvenlik başlıklarından farklı bir konudur. Tarayıcı güvenlik başlıkları, botların robots.txt veya sunucu erişim politikalarındaki davranışını tek başına belirlemez. Bu ayrımı web sitesinde yapay zekâ botları engellenmeli mi yazısındaki karar çerçevesiyle değerlendirebilirsiniz.

Web sitesi güvenlik başlıkları için uygulanabilir kontrol planı nedir?

Uygulanabilir kontrol planı, mevcut durum tespitiyle başlayıp kademeli kurulum ve yeniden test aşamalarından oluşur. Her başlık için amaç, değer, etki ve geri dönüş yöntemi kaydedilmelidir.

İlk olarak ana alan adı, www varyasyonu, alt alan adları ve CDN kullanımı listelenir. Ardından curl, tarayıcı ağı paneli ve uygun tarama araçlarıyla mevcut yanıtlar alınır. Aynı başlığın birden fazla değerde dönüp dönmediği kontrol edilir.

İkinci aşamada X-Content-Type-Options ve Referrer-Policy eklenir. JavaScript, CSS, indirme, form ve kampanya sayfaları test edilir. Dosya türü hatası veya ölçüm kaybı görülürse önce neden belirlenir, ardından politika değiştirilir.

Üçüncü aşamada HTTPS yönlendirmeleri ve sertifika zinciri kontrol edilir. HSTS önce kısa bir deneme süresiyle uygulanabilir. Alt alan adları sorunsuz çalışıyorsa süre artırılır. Preload kararı, bu kontrollerden sonra ayrıca verilir.

Dördüncü aşamada CSP Report-Only başlatılır. En azından ana sayfa, ürün veya hizmet detayları, formlar, giriş, sepet ve ödeme akışları izlenir. Raporlarda tekrar eden kaynaklar sınıflandırılır: gerekli, gereksiz, şüpheli veya hatalı.

Son aşamada politika kademeli olarak enforcement moduna geçirilir. Yayından sonra tarayıcı konsolu, sunucu logları, dönüşüm akışı ve performans metrikleri takip edilir. Bir başlık eklemek, kontrol sürecinin bittiği anlamına gelmez.

Kurumsal sitelerde iletişim formları, dosya indirmeleri, bayi portalları ve yönetim panelleri ayrıca test edilmelidir. E-ticaret sitelerinde ödeme, iade, üyelik, sipariş sorgulama ve e-posta doğrulama akışları önceliklidir.

Teknik kayıt şu alanları içerebilir: değişiklik tarihi, sorumlu kişi, eski değer, yeni değer, test edilen URL’ler, görülen hatalar ve geri dönüş kararı. Böylece sonraki bakım çalışmalarında aynı araştırma tekrarlanmaz.

Sonuç olarak güvenlik başlıkları, tek seferlik kod ekleme işi değil, ölçümlü bir bakım sürecidir. HTTPS, sunucu güvenliği, uygulama kodu ve performans kontrolleriyle birlikte ele alındığında anlamlı bir koruma katmanı oluşturur.