Content Security Policy hataları site kaynaklarını nasıl engeller?

Bir web sitesinde görsellerin yüklenmemesi, fontların bozulması, JavaScript tabanlı menülerin çalışmaması veya ödeme ekranında beklenmeyen hatalar görülmesi her zaman dosya eksikliği anlamına gelmez. Tarayıcı, Content Security Policy yani CSP kuralları nedeniyle bazı kaynakları güvenlik gerekçesiyle bilinçli olarak engelliyor olabilir. Bu durum özellikle WordPress sitelerinde tema, eklenti, CDN, reklam kodu ve üçüncü taraf servislerin birlikte çalıştığı yapılarda sık görülür.

CSP, tarayıcıya hangi alan adlarından script, stil, görsel, font, iframe veya bağlantı isteği kabul edileceğini söyleyen bir güvenlik politikasıdır. Doğru yapılandırıldığında XSS gibi saldırıların etkisini azaltır; hatalı yapılandırıldığında ise sitenin kritik kaynaklarını devre dışı bırakabilir. Bu nedenle sorun yalnızca güvenlik ekibinin değil, geliştirici, sistem yöneticisi ve içerik operasyonlarının da dikkat etmesi gereken bir konudur.

Content Security Policy kaynakları nasıl engeller?

CSP kuralları HTTP yanıt başlığı veya meta etiketi üzerinden tarayıcıya iletilir. Tarayıcı sayfayı yüklerken her kaynağı bu kurallarla karşılaştırır. Kaynak izin verilen listede değilse istek yapılmaz ya da yanıt kullanıma alınmaz. Kullanıcı tarafında bu durum genellikle bozuk tasarım, çalışmayan butonlar veya boş alanlar olarak görünür.

Örneğin siteniz hosting ortamında kendi alan adınızdan yayınlanırken, tema Google Fonts, bir analiz aracı, canlı destek betiği ve harici bir CDN kullanıyor olabilir. CSP içinde bu alan adları tanımlı değilse tarayıcı ilgili fontu, scripti veya iframe içeriğini engeller. Sunucuda dosyalar eksiksiz olsa bile kullanıcı kaynağa erişemiyor gibi bir sonuç oluşur.

En sık görülen CSP hata türleri

Script kaynaklarının engellenmesi

script-src direktifi, JavaScript dosyalarının nereden yüklenebileceğini belirler. WordPress eklentileri çoğu zaman harici servislerden betik çağırır. Bu servisler politikaya eklenmediğinde form doğrulama, sepet güncelleme, açılır pencere veya takip kodları çalışmayabilir. Konsolda genellikle “Refused to load the script” benzeri bir uyarı görülür.

Stil ve font sorunları

style-src ve font-src kuralları hatalıysa sayfanın görsel bütünlüğü bozulur. Özellikle ikon fontları yüklenmediğinde menü ikonları kare simgeye dönüşebilir. Kurumsal sitelerde bu durum marka algısını olumsuz etkiler. Inline stil kullanımını tamamen yasaklamak güvenli görünebilir; ancak tema veya sayfa oluşturucu buna hazır değilse ciddi tasarım problemleri doğurabilir.

Görsel, medya ve iframe engelleri

img-src, media-src ve frame-src direktifleri eksik olduğunda CDN görselleri, video oynatıcıları, harita bileşenleri veya ödeme sağlayıcı iframe’leri çalışmaz. E-ticaret sitelerinde ödeme sağlayıcısının iframe alanını unutmak, kullanıcıların ödeme adımında takılmasına neden olabilir.

Tarayıcı konsolunda CSP hatası nasıl okunur?

İlk kontrol tarayıcının geliştirici araçlarındaki Console sekmesinden yapılmalıdır. Hata mesajında genellikle engellenen kaynak, ilgili direktif ve uygulanan politika açıkça yazar. Örneğin violates the following Content Security Policy directive: script-src 'self' ifadesi, yalnızca aynı alan adından script yüklemeye izin verildiğini gösterir.

Burada aceleyle tüm kaynaklara izin vermek doğru yaklaşım değildir. * kullanmak, CSP’nin güvenlik değerini büyük ölçüde zayıflatır. Bunun yerine gerçekten kullanılan alan adları belirlenmeli, gereksiz eklenti ve servisler ayıklanmalı, ardından politika kontrollü şekilde güncellenmelidir.

WordPress sitelerinde pratik kontrol adımları

Önce hatanın ne zaman başladığını belirleyin. Yeni bir güvenlik eklentisi, CDN ayarı, tema güncellemesi, önbellek kuralı veya sunucu taraflı başlık değişikliği CSP davranışını değiştirmiş olabilir. Ardından önbelleği temizleyerek aynı hatanın gizli bir eski yanıttan kaynaklanmadığını doğrulayın.

İkinci adımda, devre dışı bırakmadan önce eklentilerin hangi harici kaynakları çağırdığını inceleyin. Canlı destek, reklam, analiz, pazarlama otomasyonu, harita ve ödeme entegrasyonları en çok gözden kaçan kaynaklardır. Üçüncü adımda CSP’yi doğrudan üretim ortamında sertleştirmek yerine test ortamında denemek daha güvenlidir.

Sunucu ve hosting tarafında dikkat edilmesi gerekenler

CSP başlıkları web sunucusu, güvenlik eklentisi, CDN paneli veya uygulama kodu tarafından eklenebilir. Aynı anda birden fazla katmanda tanımlama yapılırsa çakışan politikalar ortaya çıkabilir. Bu nedenle hosting paneli, CDN güvenlik ayarları ve WordPress eklentileri birlikte değerlendirilmelidir.

Apache veya Nginx üzerinde eklenen güvenlik başlıkları bazen tüm siteye genel uygulanır. Yönetim paneli, ödeme sayfası veya üyelik alanı farklı kaynaklara ihtiyaç duyuyorsa tek tip politika sorun çıkarabilir. Gerekirse belirli yollar için ayrı kural tasarlanmalı, ancak bu yapılırken güvenlik kapsamı gereksiz yere genişletilmemelidir.

Güvenli bir CSP politikası oluştururken denge nasıl kurulur?

İyi bir CSP, “her şeye izin ver” mantığıyla değil, “gereken kaynağa gerektiği kadar izin ver” prensibiyle hazırlanır. Önce default-src 'self' gibi temel bir çerçeve belirlenebilir; ardından script, stil, font, görsel ve bağlantı kaynakları ayrı ayrı tanımlanır. Inline script gerekiyorsa mümkün olduğunca nonce veya hash yaklaşımı tercih edilmelidir.

Kurumsal yapılarda değişiklik kayıt altına alınmalı ve yeni entegrasyon eklenirken CSP etkisi kontrol listesine dahil edilmelidir. Böylece bir pazarlama etiketi, yeni font ailesi veya üçüncü taraf form aracı yayına alındığında site kaynaklarının beklenmedik şekilde engellenmesi önlenir.

Hataları azaltmak için uygulanabilir öneriler

CSP’yi ilk kez devreye alıyorsanız raporlama moduyla başlamak faydalıdır. Content-Security-Policy-Report-Only başlığı, kaynakları engellemeden ihlalleri görmenizi sağlar. Bu sayede hangi alan adlarına gerçekten ihtiyaç duyulduğu anlaşılır. Ardından gereksiz çağrılar temizlenir ve politika kademeli olarak sıkılaştırılır.

Her değişiklikten sonra ana sayfa, blog yazıları, iletişim formu, üyelik girişi, ödeme akışı ve yönetim ekranı ayrı ayrı test edilmelidir. Yalnızca görsel olarak sayfaya bakmak yeterli değildir; formlar gönderilmeli, butonlar tıklanmalı ve konsol hataları kontrol edilmelidir. Böyle bir süreç, güvenliği artırırken kullanıcı deneyimini ve dönüşüm akışlarını korumaya yardımcı olur.