Content Security Policy (CSP) Nedir, Nasıl Uygulanır?

Content Security Policy (CSP), modern web projelerinde Cross-Site Scripting (XSS) ve veri enjeksiyonu saldırılarını kaynağında engellemek amacıyla geliştirilmiş W3C standardı bir güvenlik katmanıdır. Doğrudan HTTP yanıt başlıkları (HTTP response headers) üzerinden yapılandırılan bu mekanizma, tarayıcının hangi kaynaklardan (script, stil, görsel, çerçeve vb.) veri yükleyebileceğini ve hangi kodları çalıştırabileceğini kesin kurallarla belirler. Bu kapsamlı rehberde, karar vericiler ve teknik ekipler için Content Security Policy (CSP) Nedir, Nasıl Uygulanır? sorusunun yanıtını, mimari direktifleri, sıfır kesintiyle üretim ortamına geçiş adımlarını ve siber güvenlik standartlarına tam uyum pratiklerini detaylandırıyoruz.

Content Security Policy (CSP) Kavramı ve Güvenlikteki Yeri

Modern web uygulama güvenliği, yalnızca sunucu tarafında (backend) alınan tedbirlerle sınırlı kalamaz. Kullanıcının tarayıcısında (client-side) çalışan kodların bütünlüğü ve güvenilirliği, veri mahremiyeti açısından kritik bir eşiktir. Content Security Policy (CSP), tarayıcı üreticileri ve W3C konsorsiyumu tarafından standartlaştırılmış, web uygulamalarının maruz kaldığı istemci taraflı kod yürütme tehditlerini sınırlandıran bir HTTP başlık mekanizmasıdır. Temel prensip, tarayıcının varsayılan olarak her gelen kaynağı çalıştırma eğilimini kısıtlayarak, yalnızca uygulama sahibinin açıkça onayladığı güvenilir kaynak listesine (allowlist) veya kriptografik kanıtlara dayalı çalıştırma izni vermesidir.

OWASP güvenlik standartları ve ISO 27001 gereksinimleri, modern web platformlarının katmanlı bir savunma mekanizmasına sahip olmasını şart koşar. CSP, tek başına uygulamanın kaynak kodundaki tüm açıkları kapatan sihirli bir çözüm değildir; ancak güvenlik zafiyetlerinin hafifletilmesi (vulnerability mitigation) noktasında son derece güçlü bir ikinci savunma hattıdır. Bir geliştirici girdi doğrulama (input validation) veya çıktı kodlama (output encoding) aşamasında hata yapsa dahi, doğru kurgulanmış bir CSP politikası zararlı betiğin çalışmasını tarayıcı düzeyinde engelleyerek veri sızıntısının önüne geçer.

Kurumsal ölçekli dijital platformlarda CSP yapılandırmasının eksik olması, sızma testi bulguları arasında en sık rastlanan kritik eksikliklerden biridir. Finans, sağlık ve e-ticaret gibi kullanıcı verisinin regülasyonlara (KVKK, GDPR, PCI-DSS) tabi olduğu sektörlerde, istemci tarafına sızan kötü niyetli bir JavaScript parçasının oturum çerezlerini (session cookies), kimlik doğrulama belirteçlerini (tokens) veya kredi kartı form verilerini çalması şirketler için ağır mali ve hukuki yaptırımlar doğurur.

CSP'nin Tanımı ve Modern Web Mimarisindeki Rolü

Content Security Policy, HTTP protokolünün yanıt başlıkları arasına eklenen @@CODE0@@ yönergesi ile istemciye bildirilir. Tarayıcı, HTML belgesini çözümlemeye (parse etmeye) başladığı anda bu politikayı okur ve sayfa içindeki tüm varlık yükleme taleplerini bu kural setine göre denetler. Örneğin, bir HTML belgesi harici bir sunucudan @@CODE1@@ etiketini çekmeye çalıştığında, tarayıcı bu alan adının CSP script kuralları içinde yer alıp almadığını kontrol eder. Eğer kural setinde yoksa, ağ isteği tarayıcı motoru tarafından iptal edilir ve konsola bir güvenlik ihlali hatası basılır.

Geleneksel web geliştirme yaklaşımlarında satır içi (inline) JavaScript ve CSS kullanımı oldukça yaygındır. Ancak inline scriptler (@@CODE0@@ veya HTML etiketlerinin içine gömülü @@CODE1@@ gibi olay işleyicileri), XSS saldırganlarının en kolay istismar ettiği alanlardır. CSP varsayılan olarak tüm satır içi komut dosyalarının çalışmasını engeller. Bu durum, web mimarisinin ayrıştırılmış (decoupled) ve daha güvenli bir yapıya kavuşmasını mecbur kılar. Kod tabanı temizlenir ve güvenlik doğrudan tarayıcı ile sunucu arasındaki kurallar bütününe bağlanır.

Savunma Derinliği (Defense-in-Depth) Stratejisi

Bilgi güvenliğinde savunma derinliği (defense-in-depth), tek bir güvenlik katmanına güvenmek yerine birden fazla bağımsız kontrol noktası oluşturma felsefesine dayanır. Web uygulama katmanında bu yaklaşım; güvenli kod yazımı, Web Application Firewall (WAF), HTTP güvenlik başlıkları (HSTS, X-Frame-Options, CSP vb.) ve veri tabanı kısıtlamalarının senkronize çalışmasını gerektirir.

CSP Tarafından Engellenen Kritik Siber Tehditler

Web uygulamalarına yönelik saldırıların büyük bir bölümü, kullanıcının tarayıcısındaki güven ilişkisini istismar etmeyi amaçlar. Tarayıcılar, sunucudan gelen HTML içeriğindeki komutları sorgulamadan yürütmek üzere tasarlanmıştır. Bu çalışma prensibi, kötü niyetli aktörlerin hedef uygulamanın içine zararlı JavaScript parçacıkları enjekte etmesiyle felakete dönüşebilir. CSP, tarayıcının bu kör güven modelini kırarak yetkilendirme zorunluluğu getirir.

Bir e-ticaret platformunda saldırganın ödeme sayfasına JavaScript yerleştirmesi (Magecart saldırıları) veya bir bankacılık arayüzünde kullanıcının oturum token'ının ele geçirilmesi, doğrudan istemci tarafı güvenlik mekanizmalarının yetersizliğinden kaynaklanır. CSP yönergeleri, hem kodun yürütülmesini hem de ele geçirilen hassas verilerin saldırganın sunucusuna (C2 - Command & Control sunucuları) gönderilmesini eş zamanlı olarak sınırlar.

Doğru yapılandırılmış bir CSP, web uygulamasını yalnızca tek tip bir tehdide karşı değil, birbiriyle bağlantılı birçok modern istemci tarafı saldırı vektörüne karşı eşzamanlı olarak koruma altına alır.

Cross-Site Scripting (XSS) Zafiyetlerinin Bertaraf Edilmesi

Cross-Site Scripting (XSS), OWASP Top 10 listesinde yıllardır yer alan en yaygın web zafiyetlerinden biridir. Üç ana kategoride incelenir: Depolanmış (Stored XSS), Yansıtılan (Reflected XSS) ve DOM Tabanlı (DOM-based XSS). Her üç varyantın da temel amacı hedef sistemde yetkisiz JavaScript kodu çalıştırmaktır.

1. Stored XSS Koruması: Saldırganın yorum alanları veya profil bilgileri üzerinden veritabanına kaydettiği zararlı script, diğer kullanıcılar sayfayı görüntülediğinde veritabanından çekilerek çalıştırılmaya çalışılır. CSP, @@CODE0@@ direktifiyle yalnızca izin verilmiş domainleri veya hash/nonce değerlerini tanıdığı için, veritabanından gelen kontrolsüz @@CODE1@@ bloklarını doğrudan reddeder.

2. Reflected XSS Koruması: URL parametreleri üzerinden sayfaya yansıtılan payload'lar (örneğin arama kutuları üzerinden tetiklenenler), CSP'nin satır içi script engelleme kuralı sayesinde tarayıcı tarafından yorumlanmadan düz metin olarak ele alınır.

3. DOM XSS Koruması: İstemci tarafındaki JavaScript kodlarının @@CODE0@@, @@CODE1@@ veya @@CODE2@@ gibi güvensiz işlevlerle manipüle edilmesi engellenir. CSP'nin @@CODE3@@ kısıtlaması, metin dizgilerinin dinamik olarak koda dönüştürülmesini durdurur.

Veri Enjeksiyonu, Clickjacking ve Paket Koklama Saldırıları

Saldırganlar sisteme JavaScript enjekte edemeseler dahi, stil dosyaları (CSS enjeksiyonu) veya sahte görsel etiketleri aracılığıyla veri sızdırma girişiminde bulunabilirler. Örneğin, bir CSS enjeksiyonu ile form alanlarındaki karakterler tek tek arka plan görseli istekleri (@@CODE0@@) üzerinden saldırganın sunucusuna taşınabilir. CSP'nin @@CODE1@@ ve img-src direktifleri, stillerin ve görsellerin yalnızca belirli sunuculardan çekilmesini sağlayarak bu tip gizli veri sızıntı kanallarını tıkar.

Bir diğer kritik tehdit olan Clickjacking (Kullanıcı Arayüzü Giydirme), uygulamanızın kötü niyetli bir web sitesi içinde görünmez bir @@CODE0@@ içerisine yerleştirilmesiyle gerçekleştirilir. Kullanıcı zararsız görünen bir butona tıkladığında aslında iframe içindeki hassas bir işlemi (örneğin hesap silme veya para transferi) onaylamış olur. CSP'nin @@CODE1@@ direktifi, sitenizin hangi alan adları tarafından iframe içine alınabileceğini (veya tamamen engelleneceğini) belirleyerek eski nesil X-Frame-Options başlığının yerini alır ve çok daha esnek bir koruma sağlar.

# Clickjacking saldırılarını tamamen engellemek için kurumsal örnek
Content-Security-Policy: frame-ancestors 'none';

CSP Mimarisi: Direktifler (Directives) ve Kaynak Yönetimi

Content Security Policy, kaynak türlerine göre özelleştirilmiş direktifler (directives) dizisinden meydana gelir. Her direktif, ardından gelen bir veya daha fazla kaynak belirteci (source expression) ile yapılandırılır. Direktifler noktalı virgül (;) ile birbirinden ayrılır. Bir CSP politikasının etkinliği, bu direktiflerin ne kadar sıkı ve granular tanımlandığına bağlıdır.

Direktif yönetiminde mantıksal bir fallback (varsayılana dönüş) mekanizması bulunur. Birçok özel direktif tanımlanmadığında, genel kapsayıcı direktife başvurur. Bu hiyerarşiyi anlamak, hem sistemin gereksiz yere bozulmasını önlemek hem de güvenlik açıklarının oluşmasını engellemek açısından hayati bir gerekliliktir.

# Çok katmanlı, kapsamlı bir kurumsal CSP başlık örneği
Content-Security-Policy: default-src 'self'; script-src 'self' https://trustedscripts.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; img-src 'self' data: https://cdn.domain.com; font-src 'self' https://fonts.gstatic.com; connect-src 'self' https://api.domain.com; frame-ancestors 'none'; object-src 'none'; base-uri 'self';

Temel Çerçeve: default-src ve Fallback Mekanizması

@@CODE0@@, özel olarak tanımlanmamış birçok yükleme direktifinin varsayılan kaynağını belirleyen temel direktiftir. Örneğin politikanızda @@CODE1@@ veya @@CODE2@@ tanımlamamışsanız, tarayıcı bu kaynakları yüklerken @@CODE3@@ içindeki kuralları uygular.

Ancak default-src tüm direktiflerin yerine geçmez. İstisnalar ve fallback davranışları aşağıdaki tabloda özetlenmiştir:

Dinamik İçerik ve Komut Dosyası Kontrolü: script-src ve style-src

Bir web uygulamasının güvenlik omurgasını script-src oluşturur. Bu direktif, uygulamanın çalıştıracağı komut dosyalarını sınırlar. Kullanılabilecek ana anahtar kelimeler şunlardır:

• 'self': Yalnızca uygulamanın yayınlandığı aynı origin'den (protokol, domain ve port eşit olmalı) kaynak yüklenmesine izin verir.

• @@CODE0@@: İlgili kaynak türünün hiçbir koşulda yüklenmesine izin vermez (Örn: @@CODE1@@).

• https://cdn.example.com: Sadece belirtilen güvenilir alan adından veya alt yoldan script çekilmesini sağlar.

• @@CODE0@@: Satır içi kodların (@@CODE1@@ etiketleri arası veya element içi olaylar) çalışmasına izin verir. Güvenlik seviyesini ciddi oranda düşürür.

• @@CODE0@@: @@CODE1@@, @@CODE2@@, @@CODE3@@ gibi metinleri koda dönüştüren güvensiz API'lerin çalışmasına olanak tanır.

@@CODE0@@ direktifi ise CSS kaynaklarını yönetir. Modern CSS framework'leri (örneğin Tailwind CSS veya CSS-in-JS kütüphaneleri) çalışma anında dinamik stiller ekleyebildiği için ekipler genellikle @@CODE1@@ kullanma eğilimindedir. Stiller aracılığıyla yapılabilecek veri sızdırma risklerine karşı, bu direktifin de hash veya nonce mekanizmalarıyla sıkılaştırılması önerilir.

Medya, Bağlantı ve İletişim Güvenliği

Modern uygulamalar yoğun şekilde API uç noktalarıyla haberleşir ve harici medya depolarını kullanır:

• connect-src: Tek sayfa uygulamalarında (SPA - React, Vue, Angular) uygulamanın veri alışverişi yaptığı REST API veya GraphQL uç noktalarını korur. Eğer uygulamanız @@CODE0@@ adresine veri gönderiyorsa, bu adres @@CODE1@@ listesinde yer almalıdır. Aksi halde tarayıcı ağ çağrısını engeller.

• img-src: Görsellerin yükleneceği kaynakları kısıtlar. Eğer veri URI'leri (Base64 görseller) kullanılıyorsa, açıkça data: parametresi eklenmelidir.

• frame-src ve child-src: Sayfa içine gömülecek harici iframe'leri (örneğin YouTube video oynatıcıları, ödeme gateway ekranları) denetler.

Content Security Policy Nasıl Uygulanır? (Adım Adım Entegrasyon)

Content Security Policy politikasını hayata geçirmek için iki temel yöntem bulunur: Sunucu düzeyinde HTTP yanıt başlıkları tanımlamak veya HTML dokümanı içine <meta> etiketi yerleştirmek. Kurumsal ve operasyonel standartlar açısından HTTP yanıt başlıkları kullanımı her zaman öncelikli tercihtir.

CSP uygulamasının başarıya ulaşması, uygulamanın kullandığı tüm üçüncü parti servislerin (analitik araçları, canlı destek sistemleri, reklam kütüphaneleri, font sağlayıcıları) eksiksiz haritalandırılmasına bağlıdır. Yanlış yapılandırılmış bir politika, uygulamanın kritik fonksiyonlarının (örneğin ödeme formlarının veya harita modüllerinin) anında çökmesine neden olabilir.

HTTP Yanıt Başlıkları (HTTP Response Headers) ile Yapılandırma

HTTP başlıkları üzerinden yapılandırma, tüm direktiflerin (özellikle @@CODE0@@, @@CODE1@@ ve sandbox) eksiksiz çalışmasını sağlayan en güvenli yöntemdir. Bu işlem kullanılan web sunucusunun (Nginx, Apache, IIS) konfigürasyon dosyalarından veya uygulama katmanından (Node.js, .NET, Java, Go, PHP) gerçekleştirilebilir.

Nginx Yapılandırması

Nginx sunucusunda @@CODE0@@ yönergesi kullanılarak CSP global olarak veya belirli @@CODE1@@ bloklarına uygulanabilir:

server {
    listen 443 ssl http2;
    server_name sirketiniz.com;

    # Güvenlik Başlıkları
    add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://cdnjs.cloudflare.com; style-src 'self' https://fonts.googleapis.com; img-src 'self' data: https:; font-src 'self' https://fonts.gstatic.com; connect-src 'self' https://api.sirketiniz.com; frame-ancestors 'none'; object-src 'none'; base-uri 'self';" always;

    # Diğer sunucu blokları...
}

Apache Yapılandırması

Apache üzerinde @@CODE0@@ modülü aktif edilerek @@CODE1@@ veya httpd.conf dosyasına direktif eklenebilir:

<IfModule mod_headers.c>
    Header always set Content-Security-Policy "default-src 'self'; script-src 'self' https://trusted.cdn.com; style-src 'self' 'unsafe-inline'; object-src 'none'; frame-ancestors 'self';"
</IfModule>

Node.js / Express (Helmet.js) Yapılandırması

Node.js ekosisteminde popüler güvenlik ara katmanı olan helmet, CSP yapılandırmasını kod üzerinden yönetmeyi sağlar:

const express = require('express');
const helmet = require('helmet');
const app = express();

app.use(
  helmet.contentSecurityPolicy({
    directives: {
      defaultSrc: ["'self'"],
      scriptSrc: ["'self'", "https://trusted-scripts.com"],
      styleSrc: ["'self'", "https://fonts.googleapis.com"],
      imgSrc: ["'self'", "data:", "https://images.unsplash.com"],
      connectSrc: ["'self'", "https://api.domain.com"],
      objectSrc: ["'none'"],
      upgradeInsecureRequests: [],
    },
  })
);

HTML Meta Etiketi Üzerinden CSP Tanımlama

Sunucu konfigürasyonuna doğrudan müdahale edilemeyen ortamlarda (örneğin statik hosting servisleri veya bazı JAMstack yapıları) CSP, HTML belgesinin @@CODE0@@ bloğuna bir @@CODE1@@ etiketi yerleştirilerek de tanımlanabilir.

<!DOCTYPE html>
<html lang="tr">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self' https://cdn.jsdelivr.net; style-src 'self';">
    <title>Güvenli Kurumsal Portal</title>
</head>
<body>
    <!-- Uygulama Gövdesi -->
</body>
</html>

Meta Etiketinin Kritik Sınırlamaları:
Meta etiketi ile uygulanan politikalarda @@CODE0@@, @@CODE1@@, sandbox gibi tarayıcının ağ veya pencere seviyesinde yorumlaması gereken direktifler çalışmaz. Ayrıca meta etiketi tanımlanana kadar geçen sürede yüklenen kaynaklar denetim dışı kalabilir. Bu nedenle kurumsal sistemlerde meta etiketi yöntemi yalnızca zorunlu hallerde geçici bir çözüm olarak tercih edilmelidir.

Kurumsal Geçiş Stratejisi: Üretim Ortamını Bozmadan CSP Uygulamak

Milyonlarca kullanıcısı olan veya onlarca harici pazarlama kütüphanesi kullanan kurumsal bir web uygulamasında, sıkı bir CSP başlığını tek bir gecede devreye almak operasyonel bir felakete yol açabilir. Yetkilendirilmemiş bir analitik scripti çalışmadığında şirket veri kaybedebilir; ödeme sağlayıcısının iframe'i engellendiğinde ise doğrudan ticari ciro kaybı yaşanır. Bu riskleri sıfıra indirmek amacıyla W3C, Report-Only ve telemetri mekanizmalarını standardın merkezine koymuştur.

Kurumsal geçiş süreci; önce izleme, ardından analiz, sonrasında kod refaktörü (nonce/hash adaptasyonu) ve nihayetinde tam denetimli uygulama (enforcement) aşamalarından oluşmalıdır.

Content-Security-Policy-Report-Only Kullanımı

Content-Security-Policy-Report-Only başlığı, standart CSP ile birebir aynı sözdizimini (syntax) kullanır. Tek farkı: Tarayıcı ihlal oluşturan hiçbir kaynağın çalışmasını engellemez; yalnızca arka planda ihlal raporu üretir ve geliştirici konsoluna uyarı düşer.

# Canlı trafiği kesmeden ihlalleri izleyen başlık örneği
Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self' https://trusted.cdn.com; report-uri /api/csp-report-endpoint;

Bu modda sistem birkaç hafta boyunca canlı trafikte tutulur. Sayfayı ziyaret eden gerçek kullanıcıların tarayıcılarından gelen telemetri verileri toplanır. Böylece ekiplerin test ortamlarında fark edemediği üçüncü parti bağımlılıklar ve eski kod parçaları kolayca tespit edilir. Politika bu geri bildirimlerle güncellenir ve sahte-pozitif (false-positive) alarmlar sıfırlandığında başlık normal Content-Security-Policy formatına çevrilir.

report-uri ve report-to ile İhlal Raporlama Mekanizmaları

CSP ihlallerini merkezi bir SIEM (Security Information and Event Management) sistemine veya Sentry, Datadog gibi APM araçlarına yönlendirmek için raporlama direktifleri kullanılır.

• report-uri (Eski Standart - CSP Level 2): Doğrudan bir URL принимает eder. Tarayıcı ihlal gerçekleştiğinde bu adrese otomatik olarak application/csp-report JSON payload'ı postalar.

• report-to (Modern Standart - CSP Level 3): @@CODE0@@ standardını kullanır. @@CODE1@@ başlığı ile grup tanımlanır ve CSP içinde bu gruba referans verilir.

/* Tarayıcının gönderdiği örnek CSP İhlal Raporu */
{
  "csp-report": {
    "document-uri": "https://sirketiniz.com/odeme",
    "referrer": "https://google.com/",
    "blocked-uri": "https://malicious-cdn.com/bad-script.js",
    "violated-directive": "script-src 'self'",
    "original-policy": "default-src 'self'; script-src 'self'; report-uri /csp-endpoint;",
    "disposition": "enforce",
    "status-code": 200,
    "line-number": 42
  }
}

Nonce ve Hash Değerleri ile Güvenli Satır İçi (Inline) Kod İcrası

Birçok modern web uygulamasında (örneğin Google Tag Manager veya Next.js/Nuxt.js hidrasyon scriptleri), HTML içine doğrudan satır içi kod basılması zorunludur. Bu durumda 'unsafe-inline' kullanmak tüm güvenlik bariyerini yıkmak anlamına gelir. Modern CSP, bu ikilemi çözmek için iki kriptografik yöntem sunar: Nonce (Number Used Once) ve Hash (Kriptografik Özet).

1. Nonce Yöntemi (Dinamik Render Edilen Uygulamalar İçin)

Sunucu her HTTP isteğinde rastgele, tahmin edilemez ve kriptografik olarak güvenli bir Base64 dizgesi (nonce) üretir. Bu değer hem CSP başlığına hem de çalıştırılmak istenen HTML <script> etiketine öznitelik olarak eklenir.

# Sunucu yanıt başlığı (Her istekte nonce değişir)
Content-Security-Policy: script-src 'self' 'nonce-rAnd0m123456789==';

<!-- HTML Çıktısı -->
<script nonce="rAnd0m123456789==">
    console.log("Bu script güvenle çalışır.");
</script>

<!-- Bu script engellenir çünkü geçerli nonce değeri taşımaz -->
<script>
    console.log("Bu saldırgan scripti engellenir!");
</script>

2. Hash Yöntemi (Statik ve Değişmeyen Scriptler İçin)

Statik HTML veya SPA sayfalarında sunucu tarafında her istekte dinamik nonce üretmek mümkün olmayabilir. Bu durumda izin verilmek istenen inline kodun SHA-256, SHA-384 veya SHA-512 kriptografik özeti alınır ve CSP başlığına yazılır.

# Script içeriğinin SHA-256 özeti başlığa eklenir
Content-Security-Policy: script-src 'self' 'sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZGilCrJE=';

CSP Uygulamasında Yapılan Kritik Hatalar ve Riskler

Bir güvenlik mekanizmasının var olması, sistemin korunduğu anlamına gelmez; yanlış yapılandırılmış bir CSP, sahte bir güvenlik algısı (security theater) yaratarak gerçek riskleri gizler. Siber güvenlik araştırmaları ve sızma testi raporları, yaygın olarak kullanılan CSP politikalarının %70'ten fazlasının basit tekniklerle atlatılabildiğini (bypass) ortaya koymaktadır.

Geliştirici ekiplerinin karşılaştığı en büyük zorluk, eski kod tabanlarını hızlıca çalıştırma baskısıyla politikalara aşırı geniş izinler vermektir.

unsafe-inline ve unsafe-eval Direktiflerinin Yarattığı Zafiyetler

Birçok ekip, CSP'yi devreye aldıktan sonra sitenin bazı bileşenlerinin çalışmadığını görünce sorunu çözmek yerine en kolay yola başvurarak script-src * 'unsafe-inline' 'unsafe-eval' kuralını ekler. Bu tanımlama, CSP'nin XSS koruma kapasitesini neredeyse tamamen ortadan kaldırır.

• unsafe-inline Tehlikesi: Saldırganın enjekte ettiği herhangi bir <script>evilCode()</script> bloğu doğrudan çalışır.

• unsafe-eval Tehlikesi: DOM tabanlı manipülasyonlarda kullanıcı girdisi dinamik olarak koda dönüştürülebilir.

• **Wildcard (*) Kullanımı:** script-src * demek, saldırganın kendi kontrolündeki herhangi bir sunucudan script yüklemesine açık kapı bırakmak demektir.

Geniş Kapsamlı Beyaz Liste (Whitelist) Tuzakları

Sıklıkla yapılan hatalardan biri, genel CDN servislerinin kök domainlerini izinli listeye eklemektir. Örneğin script-src 'self' https://cdnjs.cloudflare.com kuralını ele alalım. CDNJS üzerinde binlerce popüler JavaScript kütüphanesi barınır. Bu kütüphaneler arasında bilinen zafiyetleri olan veya Angular/Vue gibi istemci taraflı template enjeksiyonuna (CSTI) izin veren eski sürümler de mevcuttur. Saldırgan bu genel CDN üzerinden zafiyetli bir kütüphaneyi sayfaya çağırarak CSP'yi kolayca baypas edebilir.

Aynı şekilde https://*.google.com gibi geniş joker karakterli (wildcard) tanımlar, Google'ın sunduğu JSONP uç noktalarının (Google API'leri) istismar edilerek keyfi JavaScript çalıştırılmasına zemin hazırlar.