İçerik güvenliği politikası

İçerik Güvenliği Politikası, modern tarayıcılarda siteler arası komut dosyası çalıştırma saldırılarının riskini ve etkisini önemli ölçüde azaltabilir.

Joe Medley

Mike West

Tarayıcı desteği

• 25
• 14
• 23
• 7

Kaynak

Web'in güvenlik modeli, aynı kaynak politikasına dayanır. Örneğin, https://mybank.com kaynaklı kodun yalnızca https://mybank.com verilerine erişmesi gerekir ve https://evil.example.com'a hiçbir zaman erişim izni verilmemelidir. Her kaynak, teorik olarak web'in geri kalanından izole edilir. Bu sayede geliştiriciler, uygulamalarını güvenli bir korumalı alanda oluşturabilir. Ancak pratikte saldırganlar sistemi altüst etmenin çeşitli yollarını bulmuşlardır.

Örneğin, siteler arası komut dosyası çalıştırma (XSS) saldırıları, bir siteyi kandırarak istenen içerikle birlikte kötü amaçlı kod yayınlamaya zorlayarak aynı kaynak politikasını atlar. Tarayıcılar, bir sayfada gösterilen tüm koda, söz konusu sayfanın güvenlik kaynağının meşru bir parçası olarak güvendiği için bu büyük bir sorundur. XSS Şifre Defteri, saldırganların kötü amaçlı kod ekleyerek bu güveni ihlal etmek için kullanabileceği yöntemlerin eski ancak temsili bir kesitini sunar. Bir saldırgan herhangi bir kodu başarıyla eklerse kullanıcı oturumunun güvenliğini ihlal etmiş ve özel bilgilere erişmiş olur.

Bu sayfada, modern tarayıcılarda XSS saldırılarının riskini ve etkisini azaltmaya yönelik bir strateji olarak İçerik Güvenliği Politikası (CSP) açıklanmaktadır.

CSP bileşenleri

Etkili bir CSP uygulamak için aşağıdaki adımları uygulayın:

• İzin verilenler listelerini kullanarak müşteriye nelere izin verildiğini ve nelere verilmediğini bildirin.
• Hangi yönergelerin kullanılabildiğini öğrenin.
• Hangi anahtar kelimelerin alındığını öğrenin.
• Satır içi kod ve eval() kullanımını kısıtlayın.
• Politika ihlallerini uygulamadan önce sunucunuza bildirin.

Kaynak izin listeleri

XSS saldırıları, tarayıcının uygulamanızın bir parçası olan komut dosyasını üçüncü taraflarca kötü amaçlı olarak yerleştirilen komut dosyasından ayırt edememesinden yararlanır. Örneğin, bu sayfanın alt kısmındaki Google +1 düğmesi, bu sayfanın kaynağı bağlamında https://apis.google.com/js/plusone.js adresindeki kodu yükler ve yürütür. Bu koda güveniyoruz ancak tarayıcının, apis.google.com kaynaklı kodun güvenli olduğunu, apis.evil.example.com kaynaklı kodun ise muhtemelen güvenli olmadığını kendi başına anlamasını bekleyemeyiz. Tarayıcı, kaynaktan bağımsız olarak bir sayfanın istediği tüm kodları indirip çalıştırır.

CSP'nin Content-Security-Policy HTTP üst bilgisi, güvenilir içerik kaynaklarının izin verilenler listesi oluşturmanıza olanak tanır ve tarayıcıya yalnızca bu kaynaklardaki öğeleri yürütme ya da oluşturma talimatı verir. Bir saldırgan, komut dosyası yerleştirmek için bir açık bulsa bile komut dosyası izin verilenler listesiyle eşleşmez ve bu nedenle yürütülmez.

apis.google.com'ün geçerli kod yayınlayacağına ve bizim de aynısını yapacağımıza güveniyoruz. Komut dosyalarının yalnızca bu iki kaynaktan birinden geldiğinde yürütülmesine izin veren örnek bir politika aşağıda verilmiştir:

Content-Security-Policy: script-src 'self' https://apis.google.com

script-src, bir sayfa için komut dosyasıyla ilgili ayrıcalıkları kontrol eden bir yönergedir. Bu başlık 'self' geçerli bir komut dosyası kaynağı, https://apis.google.com ise başka bir kaynaktır. Tarayıcı artık JavaScript'i HTTPS üzerinden apis.google.com'ten ve mevcut sayfanın kaynağından indirip çalıştırabilir ancak başka bir kaynaktan çalıştıramaz. Bir saldırgan sitenize kod yerleştirirse tarayıcı hata verir ve yerleştirilen komut dosyasını çalıştırmaz.

Bir komut dosyası izin verilenler listesinde olmayan bir kaynaktan çalıştırmaya çalıştığında konsolda hata gösterilir.

Politika çok çeşitli kaynaklar için geçerlidir

CSP, önceki örnekteki script-src dahil olmak üzere bir sayfanın yüklemesine izin verilen kaynaklar üzerinde ayrıntılı kontrol sağlayan bir dizi politika yönergesi sağlar.

Aşağıdaki listede, 2. seviyeden itibaren kaynak yönergelerinin geri kalanı özetlenmiştir. 3. seviye spesifikasyon taslağı hazırlanmış olsa da bu spesifikasyon, büyük tarayıcılarda genel olarak uygulanmıyor.

base-uri

Sayfanın <base> öğesinde görünebilecek URL'leri kısıtlar.

child-src

Çalışanların ve yerleşik çerçeve içeriklerinin URL'lerini listeler. Örneğin, child-src https://youtube.com, YouTube'dan video yerleştirmeye izin verir ancak diğer kaynaklardan video yerleştirmeye izin vermez.

connect-src

XHR, WebSocket'ler ve EventSource'u kullanarak bağlanabileceğiniz kaynaklarını sınırlar.

font-src

Web yazı tiplerini sunabilecek kaynakları belirtir. Örneğin, font-src https://themes.googleusercontent.com kullanarak Google'ın web yazı tiplerine izin verebilirsiniz.

form-action

<form> etiketlerinden gönderim için geçerli uç noktaları listeler.

frame-ancestors

Geçerli sayfayı yerleştirebilecek kaynakları belirtir. Bu yönerge <frame>, <iframe>, <embed> ve <applet> etiketleri için geçerlidir. <meta> etiketlerinde veya HTML kaynakları için kullanılamaz.

frame-src

Bu yönerge 2. düzeyde kullanımdan kaldırılmış ancak 3. düzeyde geri yüklenmiştir. Bu değer yoksa tarayıcı child-src değerini kullanır.

img-src

Resimlerin yüklenebileceği kaynakları tanımlar.

media-src

Video ve ses yayınlamasına izin verilen kaynaklarını kısıtlar.

object-src

Flash ve diğer eklentileri kontrol etmenizi sağlar.

plugin-types

Bir sayfanın çağırabileceği eklenti türlerini sınırlar.

report-uri

İçerik güvenliği politikası ihlal edildiğinde tarayıcının rapor gönderdiği URL'yi belirtir. Bu yönerge, <meta> etiketlerinde kullanılamaz.

style-src

Sayfanın stil sayfalarını kullanabileceği kaynaklarını sınırlar.

upgrade-insecure-requests

Kullanıcı aracılarına, HTTP'yi HTTPS olarak değiştirerek URL düzenlerini yeniden yazma talimatı verir. Bu yönerge, yeniden yazılması gereken çok sayıda eski URL'ye sahip web siteleri içindir.

worker-src

İşleyici, paylaşılan işleyici veya hizmet işleyici olarak yüklenebilecek URL'leri kısıtlayan bir CSP 3. Katman yönergesi. Temmuz 2017 itibarıyla bu yönerge sınırlı şekilde uygulanmaktadır.

Belirli bir yönerge içeren bir politika ayarlamadığınız sürece tarayıcı, varsayılan olarak ilişkili kaynağı herhangi bir kaynaktan kısıtlama olmadan yükler. Varsayılan ayarı geçersiz kılmak için bir default-src yönergesi belirtin. Bu yönerge, -src ile biten ve belirtilmemiş tüm yönergeler için varsayılan değerleri tanımlar. Örneğin, default-src değerini https://example.com olarak ayarlar ve bir font-src yönergesi belirtmezseniz yalnızca https://example.com kaynağından yazı tipi yükleyebilirsiniz.

Aşağıdaki yönergelerde yedek olarak default-src kullanılmaz. Bu ayarları yapmamanın, her şeye izin vermekle aynı olduğunu unutmayın:

• base-uri
• form-action
• frame-ancestors
• plugin-types
• report-uri
• sandbox

Temel CSP söz dizimi

CSP yönergelerini kullanmak için HTTP üstbilgisinde iki nokta işaretiyle ayrılmış şekilde listeleyin. Belirli bir türdeki tüm gerekli kaynakları tek bir talimatla aşağıdaki gibi listelediğinizden emin olun:

script-src https://host1.com https://host2.com

Aşağıda, birden fazla yönerge örneği verilmiştir. Bu örnekte, tüm kaynaklarını https://cdn.example.net adresindeki bir içerik yayınlama ağı üzerinden yükleyen ve çerçevelenmiş içerik veya eklentiler kullanmayan bir web uygulaması ele alınmıştır:

Content-Security-Policy: default-src https://cdn.example.net; child-src 'none'; object-src 'none'

Uygulama ayrıntıları

Modern tarayıcılar, ön ek eklenmemiş Content-Security-Policy başlığını destekler. Bu, önerilen başlıktır. Online eğitimlerde görebileceğiniz X-WebKit-CSP ve X-Content-Security-Policy üstbilgilerinin desteği sonlandırıldı.

CSP sayfa bazında tanımlanır. HTTP üst bilgisini, korumak istediğiniz her yanıtla birlikte göndermeniz gerekir. Bu sayede, belirli sayfalar için politikaya özel ihtiyaçlarına göre ince ayar yapabilirsiniz. Örneğin, sitenizdeki bir sayfa grubunda +1 düğmesi varsa ancak diğerlerinde yoksa düğme kodunun yalnızca gerektiğinde yüklenmesine izin verebilirsiniz.

Her yönerge için kaynak listesi esnektir. Kaynakları şemaya (data:, https:) göre veya yalnızca ana makine adına (example.com, söz konusu ana makinedeki herhangi bir kaynakla (herhangi bir şema, herhangi bir bağlantı noktası) eşleşen) göre tam nitelikli bir URI'ye (https://example.com:443, yalnızca HTTPS, yalnızca example.com ve yalnızca 443 bağlantı noktasıyla eşleşen) kadar çeşitlilik gösterecek şekilde belirtebilirsiniz. Joker karakterler kabul edilir ancak yalnızca şema, bağlantı noktası veya ana makine adının en soldaki konumunda kullanılabilir: *://*.example.com:*, herhangi bir şema kullanarak herhangi bir bağlantı noktasında example.com'un tüm alt alan adlarını (ancak example.com'un kendisini değil) eşleştirir.

Kaynak listesi dört anahtar kelimeyi de kabul eder:

• 'none' hiçbir şeyle eşleşmez.
• 'self', mevcut kaynakla eşleşir ancak alt alan adlarıyla eşleşmez.
• 'unsafe-inline' satır içi JavaScript ve CSS'ye izin verir. Daha fazla bilgi için Satır içi koddan kaçının başlıklı makaleyi inceleyin.
• 'unsafe-eval', eval gibi metinden JavaScript'e dönüştürme mekanizmalarına izin verir. Daha fazla bilgi için eval()'ten kaçının başlıklı makaleyi inceleyin.

Bu anahtar kelimeler için tek tırnak işareti gerekir. Örneğin, script-src 'self' (tırnak içinde) geçerli ana makineden JavaScript'in çalıştırılmasına izin verir; script-src self (tırnak içinde değil) ise "self" adlı bir sunucudan (mevcut ana makineden değil) JavaScript'e izin verir. Muhtemelen bunu kastetmemiştiniz.

Sayfalarınızı korumalı alana alma

Konuşulması gereken bir yönerge daha var: sandbox. Sayfanın yükleyebileceği kaynaklar yerine sayfanın yapabileceği işlemlere kısıtlamalar getirdiği için incelediğimiz diğerlerinden biraz farklıdır. sandbox yönergesi varsa sayfa, sandbox özelliğine sahip bir <iframe> içinde yüklenmiş gibi değerlendirilir. Bu durum, sayfa üzerinde çeşitli etkilere neden olabilir: Sayfayı benzersiz bir kaynağa zorlayabilir ve form göndermeyi engelleyebilir. Bu sayfanın kapsamı dışındadır ancak geçerli korumalı alan özellikleriyle ilgili tüm ayrıntıları HTML5 spesifikasyonunun "Korumalı alan" bölümünde bulabilirsiniz.

Meta etiket

CSP'lerin tercih ettiği teslimat mekanizması bir HTTP başlığıdır. Ancak doğrudan işaretlemede bir sayfa için politika ayarlamak yararlı olabilir. Bunu, http-equiv özelliğine sahip bir <meta> etiketi kullanarak yapın:

<meta http-equiv="Content-Security-Policy" content="default-src https://cdn.example.net; child-src 'none'; object-src 'none'">

Bu, frame-ancestors, report-uri veya sandbox için kullanılamaz.

Satır içi koddan kaçının

CSP yönergelerinde kullanılan kaynak tabanlı izin verilenler listeleri ne kadar güçlü olursa olsun XSS saldırılarının oluşturduğu en büyük tehdidi (satır içi komut dosyası ekleme) çözemez. Bir saldırgan doğrudan kötü amaçlı bir yükü (<script>sendMyDataToEvilDotCom()</script> gibi) içeren bir komut dosyası etiketi yerleştirebilirse tarayıcının bunu meşru bir satır içi komut dosyası etiketinden ayırt etmesi mümkün olmaz. CSP, satır içi komut dosyasını tamamen yasaklayarak bu sorunu çözer.

Bu yasak yalnızca doğrudan script etiketlerine yerleştirilmiş komut dosyalarını değil, satır içi etkinlik işleyicileri ve javascript: URL'lerini de kapsar. script etiketlerinin içeriğini harici bir dosyaya taşımanız ve javascript: URL'lerini ve <a ... onclick="[JAVASCRIPT]"> öğelerini uygun addEventListener() çağrılarıyla değiştirmeniz gerekir. Örneğin, aşağıdakileri şu şekilde yeniden yazabilirsiniz:

<script>
    function doAmazingThings() {
    alert('YOU ARE AMAZING!');
    }
</script>
<button onclick='doAmazingThings();'>Am I amazing?</button>

şuna benzer bir şeye:

<!-- amazing.html -->
<script src='amazing.js'></script>
<button id='amazing'>Am I amazing?</button>

// amazing.js
function doAmazingThings() {
    alert('YOU ARE AMAZING!');
}
document.addEventListener('DOMContentLoaded', function () {
    document.getElementById('amazing')
    .addEventListener('click', doAmazingThings);
});

Yeniden yazılan kod yalnızca CSP ile uyumlu değil, aynı zamanda web tasarımı en iyi uygulamalarına da uygundur. Satır içi JavaScript, yapıyı ve davranışı kodun kafa karıştırıcı hale getireceği şekilde karıştırır. Ayrıca, önbelleğe alma ve derleme işlemleri daha karmaşıktır. Kodunuzu harici kaynaklara taşımak, sayfalarınızın daha iyi performans göstermesini sağlar.

Sitenizi CSS tabanlı veri sızdırma saldırılarına karşı korumak için satır içi style etiketlerini ve özelliklerini harici stil sayfalarına taşımanız da önemle tavsiye edilir.

Satır içi komut dosyalarına ve stillere geçici olarak izin verme

Uyarı: Satır içi komut dosyalarının ve stillerin yasaklanması, CSP'nin en önemli güvenlik özelliğidir. Bu yöntemleri yalnızca bir komut dosyasının veya stil sayfasının kesinlikle satır içi olması gerekiyorsa kullanın.

Satır içi komut dosyalarını ve stilleri etkinleştirmek için script-src veya style-src yönergesine izin verilen bir kaynak olarak 'unsafe-inline' ekleyin. CSP 2. Katman, aşağıdaki gibi bir şifreleme tek seferlik sayısı (tek sefer kullanılan sayı) veya karma oluşturma işlemi kullanarak izin verilenler listenize belirli satır içi komut dosyaları eklemenize de olanak tanır.

Tek seferlik bir değer kullanmak için komut dosyası etiketinize bir tek seferlik değer özelliği ekleyin. Değeri, güvenilir kaynaklar listesinde bulunan bir değerle eşleşmelidir. Örneğin:

<script nonce="EDNnf03nceIOfn39fn3e9h3sdfa">
    // Some inline code I can't remove yet, but need to as soon as possible.
</script>

Tek seferlik rastgele sayıyı, nonce- anahtar kelimesinden sonra script-src yönergenize ekleyin:

Content-Security-Policy: script-src 'nonce-EDNnf03nceIOfn39fn3e9h3sdfa'

Nonces her sayfa isteği için yeniden oluşturulmalı ve tahmin edilememelidir.

Karma oluşturma işlemleri de benzer şekilde çalışır. Komut dosyası etiketine kod eklemek yerine, komut dosyasının SHA karmasını oluşturup script-src yönergesine ekleyin. Örneğin, sayfanızda şu içerik varsa:

<script>alert('Hello, world.');</script>

Politikanızda şunlar bulunmalıdır:

Content-Security-Policy: script-src 'sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZDob_Tng='

sha*- ön eki, karmayı oluşturan algoritmayı belirtir. Önceki örnekte sha256- kullanılmaktadır ancak CSP, sha384- ve sha512-'yi de destekler. Karma oluşturma işleminde <script> etiketlerini çıkarın. Baştaki ve sondaki boşluklar dahil olmak üzere büyük harf kullanımı ve boşluklar önemlidir.

SHA karma oluşturma çözümleri herhangi bir dilde kullanılabilir. Chrome 40 veya sonraki bir sürümü kullanıyorsanız Geliştirici Araçları'nı açıp sayfanızı yeniden yükleyebilirsiniz. Konsol sekmesinde, satır içi komut dosyalarınızın her biri için doğru SHA-256 karmasını içeren hata mesajları gösterilir.

eval() kullanmaktan kaçının

Bir saldırgan doğrudan komut dosyası ekleyemese bile uygulamanızı giriş metnini yürütülebilir JavaScript'e dönüştürüp kendi adına yürütecek şekilde kandırabilir. eval(), new Function(), setTimeout([string], …) ve setInterval([string], ...), saldırganların enjeksiyon yoluyla metin göndererek kötü amaçlı kod çalıştırmak için kullanabileceği vektörlerdir. CSP'nin bu riske karşı varsayılan yanıtı, bu vektörlerin tümünü tamamen engellemektir.

Bu durum, uygulama geliştirme şeklinizi aşağıdaki şekillerde etkiler:

• eval yerine yerleşik JSON.parse'ü kullanarak JSON'u ayrıştırmanız gerekir. Güvenli JSON işlemleri IE8'den sonraki her tarayıcıda kullanılabilir.

• Yaptığınız tüm setTimeout veya setInterval çağrılarını dize yerine satır içi işlevler kullanarak yeniden yazmanız gerekir. Örneğin, sayfanızda aşağıdakiler varsa:

  setTimeout("document.querySelector('a').style.display = 'none';", 10);
  

  Şu şekilde yeniden yazın:

  setTimeout(function () {
      document.querySelector('a').style.display = 'none';
  }, 10);
    ```
  

• Çalışma zamanında satır içi şablon oluşturmaktan kaçının. Birçok şablon kitaplığı, çalışma zamanında şablon oluşturma işlemini hızlandırmak için genellikle new Function() kullanır. Bu da kötü amaçlı metnin değerlendirilmesine olanak tanır. Bazı çerçeveler CSP'yi kutudan çıkar çıkmaz destekler ve eval olmadığında güçlü bir ayrıştırıcıya geri döner. AngularJS'nin ng-csp yönergesi buna iyi bir örnektir. Bunun yerine, Handlebars gibi ön derleme sunan bir şablonlama dili kullanmanızı öneririz. Şablonlarınızı önceden derlemek, kullanıcı deneyimini en hızlı çalışma zamanından bile daha hızlı hale getirebilir ve sitenizi daha güvenli hale getirebilir.

eval() veya diğer metinden JavaScript'e dönüştürme işlevleri uygulamanız için gerekliyse script-src yönergesinde izin verilen bir kaynak olarak 'unsafe-eval''ü ekleyerek bunları etkinleştirebilirsiniz. Bu yöntem, kod ekleme riski taşıdığı için kesinlikle önerilmez.

Politika ihlallerini bildirme

Kötü amaçlı eklemeye izin verebilecek hataları sunucuya bildirmek için tarayıcıya POST JSON biçimli ihlal raporlarını report-uri talimatında belirtilen bir konuma göndermesini söyleyebilirsiniz:

Content-Security-Policy: default-src 'self'; ...; report-uri /my_amazing_csp_report_parser;

Bu raporlar aşağıdaki gibi görünür:

{
    "csp-report": {
    "document-uri": "http://example.org/page.html",
    "referrer": "http://evil.example.com/",
    "blocked-uri": "http://evil.example.com/evil.js",
    "violated-directive": "script-src 'self' https://apis.google.com",
    "original-policy": "script-src 'self' https://apis.google.com; report-uri http://example.org/my_amazing_csp_report_parser"
    }
}

Raporda, politika ihlalinin nedenini bulmak için faydalı bilgiler yer alır. Bu bilgiler arasında, ihlalin gerçekleştiği sayfa (document-uri), söz konusu sayfanın referrer, sayfanın politikasını ihlal eden kaynak (blocked-uri), ihlal edilen belirli yönerge (violated-directive) ve sayfanın tam politikası (original-policy) yer alır.

Yalnızca Raporlama

CSP'yi yeni kullanmaya başladıysanız politikanızı değiştirmeden önce uygulamanızın durumunu değerlendirmek için yalnızca rapor modunu kullanmanızı öneririz. Bunu yapmak için Content-Security-Policy üstbilgisi yerine Content-Security-Policy-Report-Only üstbilgisi gönderin:

Content-Security-Policy-Report-Only: default-src 'self'; ...; report-uri /my_amazing_csp_report_parser;

Yalnızca rapor modunda belirtilen politika, kısıtlanmış kaynakları engellemez ancak ihlal raporlarını belirttiğiniz konuma gönderir. Hatta bir politikayı uygularken başka bir politikayı izlemek için her iki başlığı da gönderebilirsiniz. Bu, mevcut politikanızı uygularken CSP'nizdeki değişiklikleri test etmenin mükemmel bir yoludur: Yeni bir politika için raporlamayı etkinleştirin, ihlal raporlarını izleyin ve hataları düzeltin. Yeni politikadan memnun kaldığınızda uygulamaya başlayın.

Gerçek Dünyada Kullanım

Uygulamanız için politika oluşturmanın ilk adımı, yüklediği kaynakları değerlendirmektir. Uygulamanızın yapısını anladıktan sonra, gereksinimlerine göre bir politika oluşturun. Aşağıdaki bölümlerde, yaygın kullanım alanlarından birkaçı ve CSP yönergelerine uygun olarak bu kullanım alanlarını desteklemeyle ilgili karar süreci ele alınmaktadır.

Sosyal medya widget'ları

• Facebook'un Beğen düğmesi için çeşitli uygulama seçenekleri vardır. Sitenizin geri kalanından korumalı tutmak için <iframe> sürümünü kullanmanızı öneririz. Düzgün çalışması için child-src https://facebook.com yönergesi gerekir.
• X'in Tweet düğmesi bir komut dosyasına erişimi gerektiriyor. Sağladığı komut dosyasını harici bir JavaScript dosyasına taşıyın ve script-src https://platform.twitter.com; child-src https://platform.twitter.com yönergesini kullanın.
• Diğer platformların benzer şartları vardır ve benzer şekilde ele alınabilir. Bu kaynakları test etmek için 'none' default-src ayarlamanızı ve hangi kaynakları etkinleştirmeniz gerektiğini belirlemek için konsolunuzu izlemenizi öneririz.

Birden fazla widget kullanmak için yönergeleri aşağıdaki gibi birleştirin:

script-src https://apis.google.com https://platform.twitter.com; child-src https://plusone.google.com https://facebook.com https://platform.twitter.com

Tam gizlilik

Bazı web sitelerinde yalnızca yerel kaynakların yüklenebildiğinden emin olmak istersiniz. Aşağıdaki örnekte, her şeyi engelleyen varsayılan bir politikadan (default-src 'none') başlayarak bir bankacılık sitesi için CSP geliştirilmektedir.

Site, tüm resimleri, stili ve komut dosyasını https://cdn.mybank.net adresindeki bir CDN'den yükler ve verileri almak için XHR kullanarak https://api.mybank.com/ adresine bağlanır. Çerçeveler kullanılır ancak yalnızca siteye yerel sayfalar için (üçüncü taraf kaynakları yok) Sitede Flash, yazı tipi veya ek öğe yoktur. Gönderebileceği en kısıtlayıcı CSP başlığı şudur:

Content-Security-Policy: default-src 'none'; script-src https://cdn.mybank.net; style-src https://cdn.mybank.net; img-src https://cdn.mybank.net; connect-src https://api.mybank.com; child-src 'self'

Yalnızca SSL

Aşağıda, forumundaki tüm kaynakların yalnızca güvenli kanallar kullanılarak yüklenmesini sağlamak isteyen ancak kodlama konusunda deneyimli olmayan ve satır içi komut dosyaları ve stillerle dolu üçüncü taraf forum yazılımını yeniden yazmak için kaynakları olmayan bir forum yöneticisi için örnek bir CSP verilmiştir:

Content-Security-Policy: default-src https:; script-src https: 'unsafe-inline'; style-src https: 'unsafe-inline'

https:, default-src içinde belirtilmiş olsa da komut dosyası ve stil yönergeleri bu kaynağı otomatik olarak devralmaz. Her yönerge, söz konusu kaynak türü için varsayılan değerin üzerine yazar.

CSP standardı geliştirme

İçerik Güvenliği Politikası 2. Katman, W3C tarafından önerilen bir standarttır. W3C'nin Web Uygulaması Güvenliği Çalışma Grubu, spesifikasyonun bir sonraki iterasyonunu (İçerik Güvenliği Politikası 3. Seviye) geliştiriyor.

Yakında kullanıma sunulacak bu özelliklerle ilgili tartışmaları takip etmek için public-webappsec@ posta listesi arşivlerini inceleyin.