HTTP Güvenlik Başlıkları: CSP ve Referrer-Policy Rehberi

HTTP güvenlik başlıkları, tarayıcıya sayfanın nasıl davranması gerektiğini söyleyen yanıt satırlarıdır. En çok iş yapan ikisi Content-Security-Policy (CSP) ve Referrer-Policy'dir. CSP hangi kaynakların yüklenebileceğini sınırlar, Referrer-Policy ise bir bağlantıya tıklandığında karşı tarafa ne kadar adres bilgisi gideceğini belirler. Bir e-spor kulübünün sitesini, bir maç takvimini ya da sponsorlu bir yayın sayfasını yönetiyorsanız, doğru sıra şudur: önce sayfanın ne yüklediğini çıkarın, politikayı rapor modunda deneyin, raporları okuyun ve ancak sonra zorunlu kılın.

Güvenlik başlıkları neyi korur, neyi korumaz

MDN'nin güvenlik sayfası (yeni sekmede açılır), bir sitenin izlemesi gereken pratikleri kısa bir listeyle sayar. Listede HTTPS kullanmak, bir Content Security Policy tanımlamak, çerezlerin erişimini sınırlamak ve dışarıdan yüklenen betikler için Subresource Integrity kullanmak yer alır. Aynı sayfa, sitenizin bu pratiklere uyup uymadığını taramak için HTTP Observatory aracını da anar. Yani başlıklar tek başına bir güvenlik duvarı değil, daha geniş bir savunma düzeninin parçasıdır.

Bu ayrım önemlidir, çünkü başlık eklemek giriş sayfasındaki bir açığı, zayıf bir yönetici parolasını ya da güncellenmemiş bir eklentiyi kapatmaz. MDN'nin CSP sayfası da aynı sınırı çizer: CSP girdi temizlemenin yerine geçmez. Siteler girdiyi temizlemeli ve ayrıca CSP koymalıdır, böylece XSS'e karşı derinlemesine savunma kurulur.

Tablo: Bu başlıkların işi.

Bu başlıkların bir sayfanın aramadaki sırasını yükselttiğini söyleyen bir ifade MDN sayfalarında yoktur. Başlıkları güvenlik ve gizlilik kararı olarak ele alın, sıralama vaadi olarak değil.

Başlığa dokunmadan önce: sayfanız neleri yüklüyor

CSP'yi yazmanın en zor kısmı sözdizimi değil, sayfanın gerçekte hangi kaynakları kullandığını bilmektir. Örnek senaryo: bir e-spor kulübünün sitesinde canlı yayın gömmesi, bir sohbet topluluğu eklentisi, sponsor afişleri, takım fotoğrafları, maç takvimi için bir üçüncü taraf widget'ı, bir ölçüm betiği ve bir bülten formu vardır. Bunların her biri farklı bir alan adından gelir ve her biri ayrı bir CSP kararı gerektirir.

Envanteri çıkarmak için pratik adımlar

Uygulama önerisi: tarayıcı geliştirici araçlarındaki ağ sekmesini açın, sayfayı çerez onayı verilmiş ve verilmemiş iki durumda yükleyin ve çıkan alan adlarını türüne göre gruplayın. Betik, stil, görsel, yazı tipi, çerçeve (iframe) ve bağlantı (fetch, WebSocket) olarak ayırın. Ayrıca tema ve eklentilerin sayfa kaynağına yazdığı satır içi betikleri ve stil bloklarını not edin, çünkü bunlar CSP'yi en çok zorlayan kalemlerdir.

• Sayfanın kendi alan adından gelen betikler ve stiller
• Reklam, analiz ve etiket yönetimi betikleri ile bunların sonradan yüklediği başka betikler
• Gömülü yayın, video ve harita çerçeveleri
• Satır içi betikler ve olay işleyicileri (onclick gibi)
• Formların gönderildiği adresler
• Giriş yapmış kullanıcıya ya da yönetici paneline ait sayfalar (ayrı politika gerekebilir)

Üçüncü taraf betiklerin performans yükünü ayrıca üçüncü taraf betik denetimi yazısındaki yöntemle ölçebilirsiniz. Aynı envanter hem güvenlik hem hız kararı için işe yarar.

CSP'nin mantığı: yönergeler ve kaynak listeleri

MDN'nin CSP sayfasına (yeni sekmede açılır) göre CSP'nin ana kullanım amacı, bir belgenin özellikle JavaScript kaynaklarından hangilerini yükleyebileceğini denetlemektir ve bu, esas olarak çapraz site betik çalıştırma (XSS) saldırılarına karşı savunma için kullanılır. Politika, Content-Security-Policy yanıt başlığıyla tarayıcıya iletilir. MDN, bunun yalnız ana belgede değil, tüm isteklere verilen tüm yanıtlarda ayarlanması gerektiğini söyler.

Tablo: MDN'de anlatılan başlıca yönergeler.

MDN'deki basit örnek, default-src için yalnız kendi kaynağa izin verip görselleri kendi alan adınız ve bir ek alan adından almaktır. Bu kadar sıkı bir politika, e-spor senaryosundaki gibi yayın, sponsor ve widget kullanan bir sitede ilk günden çalışmaz. Bu yüzden rapor modu vardır.

CSP'ye rapor modunda başlamak

MDN'ye göre dağıtımı kolaylaştırmak için CSP rapor modunda yayınlanabilir. Bunun için Content-Security-Policy-Report-Only başlığı kullanılır. Politika zorlanmaz, fakat ihlaller politikada belirtilen rapor uç noktasına gönderilir. Her iki başlık birlikte varsa Content-Security-Policy ile verilen politika zorlanır, Report-Only ile verilen ise yalnız rapor üretir. Böylece mevcut politikanız yerinde dururken, daha sıkı bir sonraki sürümü canlı trafikte deneyebilirsiniz.

MDN'nin bir kısıtını not edin: normal bir CSP meta öğesiyle verilebilir, fakat rapor modundaki politika meta öğesiyle iletilemez. Rapor modu için gerçek bir HTTP başlığına ihtiyacınız vardır. MDN'ye göre meta yolu, yalnız statik kaynakları olan istemci tarafı tek sayfa uygulamaları gibi sunucu altyapısına bağlı kalmak istemeyen durumlarda yararlıdır, ama tüm CSP özelliklerini desteklemez.

Rapor modunda bir deneme döngüsü

1. Envanterden bir ilk politika yazın ve Report-Only başlığıyla yayınlayın.
2. Raporları bir süre toplayın. Süreyi sitenizin trafiğine ve sayfa çeşitliliğine göre siz belirlersiniz, belgelerde bir süre önerisi yoktur.
3. Raporlanan ihlalleri meşru (envantere eklenmeli) ve beklenmeyen kaynak diye ayırın.
4. Politikayı düzeltin, tekrar rapor modunda yayınlayın.
5. Raporlar sakinleşince politikayı Content-Security-Policy başlığına taşıyın.

Raporları toplamak: Reporting-Endpoints ve report-uri

MDN'nin önerdiği yol Reporting API'dir. Reporting-Endpoints başlığıyla bir uç nokta adı tanımlanır, politikada report-to yönergesi bu adı anar. Raporlar POST ile ve application/reports+json içerik türüyle gelir, nesne türü csp-violation olan bir yapı taşır. Eski yöntem report-uri, application/csp-report içerik türüyle POST gönderir. MDN bu yaklaşımın kullanımdan kalktığını yazar, fakat report-to tüm tarayıcılarda desteklenene kadar ikisinin de tanımlanmasını önerir.

Uç noktanızın bu iki içerik türünü de kabul etmesi gerekir. Kendi sunucunuzda bir toplayıcı yazmak yerine rapor toplayan bir hizmet kullanabilirsiniz. O durumda ihlal raporlarına kullanıcıların gezdiği sayfa adresleri girebileceğinden, hizmetin saklama süresini ve gizlilik koşullarını gözden geçirin. Bu bir uygulama önerisidir.

Rapor satırlarını ayıklamak: karar kuralı

Uygulama önerisi: toplanan her ihlali üç kutudan birine koyun. Birinci kutu, sizin bildiğiniz ve sayfanın çalışması için gereken kaynaklardır. Bunları politikaya ekleyin. İkinci kutu, bildiğiniz fakat gereksiz kaynaklardır, örneğin eski bir eklentinin hâlâ çağırdığı bir betik. Bunları politikaya eklemek yerine sayfadan kaldırın, böylece hem saldırı yüzeyi hem sayfa yükü küçülür. Üçüncü kutu, kimin eklediğini bilmediğiniz kaynaklardır. Bunlar araştırma gerektirir: bir ekip üyesinin eklediği bir widget mı, bir eklenti güncellemesinin getirdiği bir betik mi, yoksa sayfaya beklenmedik biçimde enjekte edilmiş bir şey mi? MDN, CSP'nin XSS'e karşı savunma için olduğunu söylediğinden, üçüncü kutudaki satırlar politikaya eklenmeden önce açıklanmalıdır.

Raporların gürültü üretebileceğini baştan kabul edin ve ilk haftanın raporlarını bir tablo ya da basit bir çalışma sayfasında alan adı ve yönerge bazında gruplayın. Aynı alan adının birçok sayfadan gelmesi, tek tek sayfa düzeltmek yerine merkezî bir kural gerektiğini gösterir.

Nonce, hash ve unsafe-inline

MDN, satır içi betik sorununu iki yolla çözmeyi anlatır. Nonce yönteminde sunucu her yanıt için rastgele bir değer üretir, bu değeri hem başlığa hem betik öğesinin nonce niteliğine yazar. MDN'ye göre nonce her HTTP yanıtında farklı olmalı ve tahmin edilememelidir. Bunun sonucu şudur: sunucu statik HTML veremez, şablonlama gerekir. Hash yönteminde ise betiğin SHA-256, SHA-384 ya da SHA-512 özeti hesaplanır ve Base64 olarak önekle eklenir. Dış betiklerde bu yöntemin çalışması için integrity niteliği de gerekir. Hash yönteminde CSP ve içerik statik kalabilir.

unsafe-inline için MDN'nin ifadesi nettir: geliştiriciler bundan kaçınmalıdır, çünkü CSP'nin amacının büyük kısmını boşa çıkarır. Bir yönergede nonce ya da hash varsa tarayıcılar unsafe-inline'ı yok sayar. unsafe-eval ise nonce ya da hash olsa bile çalışmaya devam eder ve MDN bundan da kaçınılmasını söyler. MDN'nin önerdiği sıkı CSP biçimi, nonce ya da hash tabanlı script-src ile object-src 'none' ve base-uri 'none' birleşimidir.

Karar tablosu: Satır içi betik yöntemi seçimi.

Önbellek notu uygulama çıkarımıdır: nonce her yanıtta farklı olması gerektiği için, tam sayfa önbelleği kullanan bir sitede nonce üretimi önbellek katmanıyla birlikte düşünülmelidir. Belgelerde bu konuda ayrı bir ifade yoktur, hosting ya da eklenti desteğinizi sınayın.

Reklam ve analiz scriptleri CSP'yi nasıl etkiler

Sponsorlu ve reklamlı siteler için asıl zorluk burada başlar. Bir reklam ya da etiket yönetimi betiği başka alan adlarından başka betikler, görseller ve çerçeveler getirebilir. Allowlist yaklaşımı, yani her alan adını tek tek yazmak, MDN'ye göre doğru kurması zor bir yaklaşımdır ve politikalar yanlışlıkla güvenli olmayan alan adlarına izin verebilir. MDN'nin alternatifi nonce ya da hash tabanlı strict CSP ve gerekirse strict-dynamic'tir.

Karar kuralı: Bir üçüncü taraf betiği yükleyen sayfada önce betiğin hangi alan adlarına bağlandığını rapor modunda görün. Beklenen alan adları reklam ağınızın belgesinde varsa onları not edin, yoksa sağlayıcıdan listeyi isteyin. Sonra şu üç yoldan birini seçin.

1. Betiğe nonce verip strict-dynamic ile sonradan yüklenenlere izin vermek. Daha az liste bakımı, ama MDN'nin uyardığı gibi daha zayıf koruma.
2. İlgili alan adlarını script-src, img-src ve frame-src listelerine yazmak. Liste bakımı sizdedir, sağlayıcı alan adı eklediğinde sayfa bozulabilir.
3. Reklam ya da widget'ı ayrı bir sayfada ya da çerçevede tutup ana sayfa politikasını sıkı bırakmak.

Çerez onayı akışı da burada rol oynar. Onay verilmeden yüklenmeyen betikler, onaydan sonra ekleneceği için CSP'nin iki durumu da kapsaması gerekir. Onay ve ölçüm kaybı konusunu çerez onayı ve Consent Mode yazısında bulabilirsiniz. Reklam yerleşimlerinin sayfa hızına etkisi ise reklam ve Core Web Vitals dengesi yazısının konusudur.

Sağlayıcıya sorulacak sorular

Reklam ya da sponsor entegrasyonu eklemeden önce sağlayıcıdan yazılı yanıt isteyin. Betik hangi alan adlarından yüklenir ve bu liste değiştiğinde size haber verilir mi? Sağlayıcı nonce ile çalışan bir yükleme biçimi sunuyor mu? Betik eval kullanıyor mu? Sağlayıcı kendi belgesinde bir CSP örneği veriyor mu? Bu yanıtlar CSP'nin bakım yükünü belirler. Yanıtlar belirsizse politikayı rapor modunda daha uzun tutun ve reklam alanı için ayrı bir sayfa ya da çerçeve düşünün. MDN bu konuda sağlayıcıya özel bir ifade içermez, bu nedenle kesin yanıt sağlayıcının kendi belgesindedir.

Gömülü içerik: frame-ancestors ve frame-src

Çerçeve ile ilgili iki ayrı yön vardır ve karıştırılır. frame-src, sizin sayfanızın hangi dış çerçeveleri (yayın, video, harita) gömebileceğini söyler. frame-ancestors ise sizin sayfanızın başkaları tarafından gömülüp gömülemeyeceğini söyler. MDN'ye göre sitenizin gömülebilir olması gerekmiyorsa frame-ancestors 'none' olarak ayarlanmalıdır ve bu yönerge X-Frame-Options başlığının daha esnek bir karşılığıdır.

Örnek senaryo: kulüp, turnuva sonuç tablosunu bir ortak sitenin kendi sayfasında göstermesine izin vermek istiyor. O halde frame-ancestors 'none' yerine yalnız o ortağın alan adını listeler. Yayın gömmesi için ise kendi sayfasının frame-src listesine yayın platformunun alan adını ekler. Alan adlarını platformun güncel gömme belgesinden doğrulayın, burada sabit bir liste yazılmaz.

Referrer-Policy: değerler ve varsayılan

MDN'ye göre (yeni sekmede açılır) Referrer-Policy yanıt başlığı, Referer başlığıyla gönderilecek yönlendiren bilgisinin ne kadarının isteklere ekleneceğini denetler. Başlık adındaki yazım farkı (Referer ve Referrer) bilinen bir tuhaflıktır, Referrer-Policy adı ise iki r ile yazılır. Ayrıca MDN, politika belirtilmediğinde ya da geçersiz bir değer verildiğinde varsayılanın strict-origin-when-cross-origin olduğunu yazar. Eskiden varsayılan no-referrer-when-downgrade idi.

Tablo: Referrer-Policy değerleri.

MDN unsafe-url için açık bir uyarı yapar: HTTPS kaynak adreslerindeki özel olabilecek bilgileri güvensiz kökenlere sızdırır, etkisini dikkatle değerlendirin. Adreslerinde kullanıcıya ya da siparişe ait bilgi taşıyan sitelerde bu uyarı doğrudan geçerlidir.

Hangi değeri seçmeli: karar kuralı

• Adreslerinizde kişisel ya da özel bilgi (e-posta, sipariş numarası, davet kodu) taşımıyorsanız varsayılan değer yeterli olabilir. Başlığı açıkça yazmak niyetinizi belgeler.
• Adreslerde özel bilgi varsa ya da dış sitelere hiçbir şey göndermek istemiyorsanız same-origin ya da no-referrer değerlerini değerlendirin. Bunun bir bedeli vardır, ortak siteler ve ölçüm araçları sizden gelen trafiğin kaynağını daha az görür.
• Yalnız köken paylaşmak istiyorsanız origin ya da strict-origin kullanın.
• unsafe-url için gerçek bir gerekçeniz yoksa kullanmayın.

Başlığın yanında HTML ve bağlantı düzeyi seçenekler

MDN üç ek yol anlatır. Birincisi, sayfanın tamamı için meta öğesi: name değeri referrer olur ve değer tireli yazılır (no-referrer). İkincisi, a, area, img, iframe, script ve link öğelerinde referrerpolicy niteliği. Üçüncüsü, a, area ve link öğelerinde rel değeri noreferrer; bu değer tiresiz yazılır. İkisinin yazımının farklı olduğuna MDN özellikle dikkat çeker. Birden fazla değer yalnız HTTP başlığında kullanılabilir, böylece bir tarayıcı yeni değeri desteklemezse sıradaki yedek değer kullanılır. Referrerpolicy niteliğinde bu desteklenmez.

MDN'nin diğer önerileri: çerez, SRI ve çapraz köken

CSP ve Referrer-Policy listenin yalnız iki maddesidir. MDN'nin güvenlik sayfasında geçen diğer pratikler şunlardır: SameSite niteliğini mümkünse Strict, değilse Lax yapmak. Mümkünse Secure ve HttpOnly niteliklerini eklemek. Giriş yapmış kullanıcıyı temsil eden çerezlerin ömrünü kısa tutmak. Dış kaynaklı betiklerde (CDN gibi) Subresource Integrity kullanmak. Çapraz köken isteklerini hangi koşullarda kabul edeceğinize karar verip fetch metadata ile denetlemek. Kaynak kodu erişimini, gizli değerleri ve bağımlılıkları denetlemek.

HSTS, güvenlik başlıkları arasında anılan ayrı bir başlıktır. Kurulumu ve riskleri karma içerik konusunun parçasıdır. MDN'nin CSP sayfası da upgrade-insecure-requests yönergesinin HSTS'nin yerini tutmadığını söyler.

Başlıkları sunucuda yayınlamak ve test etmek

Başlıklar sunucu yapılandırmasında, bir CDN ya da koruma katmanının kural ekranında ya da uygulama kodunda eklenebilir. Hangisini seçeceğiniz hosting planınıza bağlıdır ve burada bir sağlayıcı talimatı yazılmaz. Önemli olan, başlığın yalnız ana HTML'ye değil, MDN'nin dediği gibi tüm yanıtlara eklenmesidir. Tek bir katmanda tanımlayın, aynı başlığı iki katmanda tekrar etmeyin. Bu bir uygulama önerisidir.

Koruma katmanı (WAF) ve bot yönetimi kuralları da yanıt başlıklarına dokunabilir ve bazı kurallar tarama botlarını etkileyebilir. Ayrıntı için kötü bot trafiği ve Googlebot yazısına bakın.

Yayın öncesi test listesi

• Başlık canlı yanıtta görünüyor mu (tarayıcı araçları ya da komut satırı ile)?
• Ana sayfa, makale, takım sayfası, form sayfası ve giriş sayfası ayrı ayrı açılıyor mu?
• Konsolda CSP ihlali hatası var mı?
• Canlı yayın gömmesi, ölçüm betiği ve reklam alanı çalışıyor mu?
• Çerez onayı verilmiş ve verilmemiş durumlar denendi mi?
• Mobil tarayıcıda ve en az iki farklı tarayıcıda denendi mi?
• Search Console URL Denetimi canlı sınaması sayfayı beklenen içerikle gösteriyor mu?

Son madde bir uygulama önerisidir: CSP bir betiği engellerse sayfa içeriği eksik oluşabilir. Google'ın gördüğü sayfayı URL Denetimi ile karşılaştırmak bu durumu erken yakalar.

Geri alma planı

Başlıkları yayınlamadan önce nasıl geri alacağınızı yazın. Uygulama önerisi: değişikliği tek bir yapılandırma satırı ya da tek bir kural olarak tutun, önceki halini kaydedin ve geri almanın kimin yetkisinde olduğunu belirleyin. Politikayı önce bir sayfa grubunda (örneğin yalnız blog) zorunlu kılıp sonra genişletmek, hatanın etkisini sınırlar.

Yayından sonra izleme

Politika zorunlu hale geldikten sonra da rapor uç noktasını açık tutun. Sitenize yeni bir widget, yeni bir sponsor ya da yeni bir eklenti eklendiğinde ihlaller yeniden görünür. Uygulama önerisi: her yeni üçüncü taraf bileşeni için bir kontrol maddesi tutun: bileşen eklenmeden önce hangi alan adlarını kullandığı kaydedilsin, politika güncellensin ve test listesi yeniden çalıştırılsın. Bu alışkanlık, bir sezon açılışında yeni sponsor afişi eklendiğinde sayfanın sessizce bozulmasını önler.

Örnek takvim: iki haftalık başlangıç

Örnek senaryo: kulüp sitesi bir yönetici ve bir gönüllü geliştirici tarafından yönetiliyor. Birinci hafta envanter çıkarılır ve Referrer-Policy başlığı yayınlanır, çünkü bu başlığın etkisi dış trafik kaynağı raporlarında kolay gözlenir. İkinci hafta CSP rapor modunda yayına alınır. Sonraki dönemde raporlar okunur, politika düzeltilir ve önce blog bölümünde, sonra tüm sitede zorunlu kılınır. Bu zamanlama bir öneridir, MDN süre vermez. Referrer-Policy değişiminden sonra kaynak raporlarını izleyin, çünkü ortak siteler ve ölçüm araçları gelen trafiğin kaynağını farklı görebilir.

Genel site güvenliği kontrolü için web sitesi güvenliği ve hosting kontrol listesi yazısına da bakabilirsiniz.

Başlık envanteri tablosu

Başlıklar bir kez yazılıp unutulursa sunucu taşındığında ya da bir eklenti güncellendiğinde sessizce kaybolur. Bunu önlemek için küçük bir başlık envanteri tutun: her satırda sayfa türü, gönderilen başlık, değerin kısa özeti, kimin eklediği ve son doğrulama tarihi yazsın. Tek bir tablo yeterlidir.

Sayfa türlerini ayırmak önemlidir, çünkü ana sayfa, içerik sayfası, giriş formu ve ödeme adımı aynı kaynakları yüklemez. Giriş ve ödeme gibi hassas sayfalarda politika daha dar, reklam ve gömülü içerik taşıyan sayfalarda daha geniş olabilir; farkın nedeni envanterde yazılı olmalıdır.

Uygulama önerisi: her başlık değişikliğinden sonra aynı yedi sayfayı elle açın ve tarayıcı konsolunda ihlal uyarısı arayın: ana sayfa, bir içerik sayfası, arama sayfası, giriş sayfası, form sayfası, hata sayfası ve gömülü içerikli bir sayfa. Hata sayfasını unutmayın; hata yanıtları ayrı bir şablondan ya da doğrudan sunucudan geldiğinde başlıklar eksik kalabilir.

Başlıkları kontrol eden otomatik bir betik yazmak isterseniz betiğin görevi yalnız başlığın varlığını ve değerin beklenen kalıpla başladığını doğrulamak olsun. Betik politikayı yorumlamaya çalıştığında yanlış alarm üretir ve ekip uyarılara güvenmeyi bırakır.

Envanter aynı zamanda ajans ve sağlayıcı değişikliklerinde devir belgesidir. Yeni ekip hangi başlığın neden konduğunu satırdan okur; bir başlığı kaldırmak isterse önce o satırdaki gerekçeyi gözden geçirir. Gerekçesi yazılmamış bir başlık ilk sorunda “bunu kim koydu” sorusunu doğurur ve aceleyle kaldırılır; oysa o başlık güvenlik için gerekli olabilir.

Karıştırılan noktalar

İlk karışıklık, X-Frame-Options ile frame-ancestors'ı bağlantısız iki şey sanmaktır. MDN frame-ancestors'ı X-Frame-Options'ın daha esnek bir karşılığı olarak tanıtır. İkinci karışıklık, meta öğesiyle CSP vermenin her şeyi kapsadığını varsaymaktır. MDN meta yolunun tüm özellikleri desteklemediğini ve rapor modunun meta ile verilemediğini söyler. Üçüncüsü, Referer ile Origin başlığını aynı sanmaktır. MDN, GET ve HEAD isteklerinde ve cors modundaki isteklerde politikanın Origin başlığını değiştirmediğini anlatır. Dördüncüsü, yazımı karıştırmaktır: bağlantılarda rel değeri tiresiz noreferrer, meta öğesinde ise tireli no-referrer yazılır.

Sık Sorulan Sorular

CSP aramada sıralamamı yükseltir mi?

MDN sayfaları CSP ve Referrer-Policy başlıklarını güvenlik ve gizlilik aracı olarak anlatır, sıralamaya etkisi hakkında bir ifade içermez. Başlıkları güvenlik kararı olarak ele alın.

CSP'yi doğrudan zorunlu kılabilir miyim?

Teknik olarak evet, fakat MDN dağıtımı kolaylaştırmak için rapor modunu önerir. Zorunlu kılınan hatalı bir politika betikleri, çerçeveleri ve görselleri engelleyebilir.

Rapor modu meta öğesiyle çalışır mı?

Hayır. MDN, rapor modundaki politikanın meta öğesiyle iletilemediğini yazar. Content-Security-Policy-Report-Only gerçek bir HTTP başlığı olarak gönderilmelidir.

Referrer-Policy yazmazsam ne olur?

MDN'ye göre politika belirtilmezse ya da geçersiz değer verilirse varsayılan strict-origin-when-cross-origin olur. Eskiden varsayılan no-referrer-when-downgrade idi.

Reklam betiklerini CSP'ye nasıl eklerim?

MDN alan adı listesinin doğru kurulmasının zor olduğunu, nonce ya da hash tabanlı politikanın tercih edildiğini ve strict-dynamic'in kolaylık sağlarken korumayı azalttığını anlatır. Hangi alan adlarının gerektiği ise reklam sağlayıcınızın belgesindedir.

unsafe-inline kullanmak sorun olur mu?

MDN geliştiricilerin unsafe-inline'dan kaçınmasını söyler, çünkü CSP'nin amacının büyük kısmını boşa çıkarır. Yönergede nonce ya da hash varsa tarayıcı unsafe-inline'ı yok sayar.

Sonuç

Güvenlik başlıkları sihirli bir kalkan değil, birkaç somut işi yapan ayarlardır. CSP hangi kaynakların çalışacağını sınırlar, Referrer-Policy giden adres bilgisini kısar, frame-ancestors sayfanızın gömülmesini denetler. Güvenli yol, envanterden başlayıp Report-Only ile raporları toplamak, reklam ve ölçüm betiklerini ayrı bir karar olarak ele almak, her değişikliği geri alınabilir tutmaktır. Başlıkları sıralama vaadiyle değil, savunma düzeninin parçası olarak yayınlayın ve her değişiklikten sonra sayfa işlevlerini ve ölçüm kaynaklarını yeniden kontrol edin.

Siteniz sağlam bir temel üzerinde olduktan sonra görünürlük çalışmasına geçebilirsiniz. Bağlantı kazanımı için backlink paketlerimizi inceleyebilirsiniz.