İçerik güvenliği politikası

İçerik Güvenliği Politikası, modern tarayıcılarda siteler arası komut dosyası 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 kodunun yalnızca https://mybank.com verilerine erişebilmesi gerekir ve https://evil.example.com uygulamasına hiçbir zaman erişim izni verilmemelidir. Her kaynak teoride web'in geri kalanından ayrı tutulur ve geliştiricilere derlemeleri için güvenli bir korumalı alan sağlar. Ancak pratikte, saldırganlar sistemi yıkmanın birçok yolunu buldular.

Siteler arası komut dosyası çalıştırma (XSS) saldırıları, örneğin bir siteyi amaçlanan içerikle birlikte kötü amaçlı kod yayınlaması için kandırarak aynı kaynak politikasını atlar. Tarayıcılar bir sayfada gösterilen tüm kodların, o sayfanın güvenlik kaynağının meşru bir parçası olarak kabul edildiğinden, bu büyük bir sorundur. XSS Kısa Notları, bir saldırganın kötü amaçlı kod yerleştirerek bu güveni ihlal etmek için kullanabileceği yöntemlerin eski ancak temsili bir kesişimidir. Bir saldırgan herhangi bir kodu başarıyla yerleştirirse kullanıcı oturumunun güvenliğini ihlal etmiş ve özel bilgilere erişim sağlamıştır.

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ı (İGP) özetlenmektedir.

CSP bileşenleri

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

• İzin verilen ve verilmeyen içerikleri müşteriye bildirmek için izin verilenler listelerini kullanın.
• Kullanılabilir yönergeleri öğrenin.
• Kullandıkları anahtar kelimeleri öğrenin.
• Satır içi kod ve eval() kullanımını kısıtlayın.
• Politika ihlallerini zorunlu kılmadan önce sunucunuza bildirin.

Kaynak izin verilenler listeleri

XSS saldırıları, tarayıcının, uygulamanızın parçası olan komut dosyası ile üçüncü bir tarafça kötü amaçlı olarak yerleştirilen komut dosyasını birbirinden ayırt edememesinden faydalanı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 ancak apis.evil.example.com kodunun güvenli olmadığını kendi başına anlamasını bekleyemiyoruz. Tarayıcı, kaynağından bağımsız olarak sayfanın istediği kodu memnuniyetle indirir ve yürütür.

CSP'nin Content-Security-Policy HTTP üst bilgisi, güvenilir içerik kaynaklarından oluşan bir izin verilenler listesi oluşturmanıza olanak tanır ve tarayıcıya yalnızca bu kaynaklardan gelen kaynakları yürütmesini veya oluşturmasını söyler. Bir saldırgan, komut dosyası eklemek için bir delik bulabilse bile komut dosyası izin verilenler listesiyle eşleşmez ve bu nedenle yürütülemez.

Geçerli kod sunma konusunda apis.google.com uygulamasına güveniyor, aynısını yapma konusunda da kendimize güveniyoruz. Komut dosyalarının yalnızca bu iki kaynaktan birinden geldiklerinde yürütülmesine izin veren bir politikayı burada görebilirsiniz:

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

script-src, bir sayfa için komut dosyasıyla ilgili bir dizi ayrıcalığı kontrol eden bir yönergedir. Bu üst bilgi, geçerli bir komut dosyası kaynağı olarak 'self' ve başka bir komut dosyası kaynağı olarak https://apis.google.com. Tarayıcı artık JavaScript'i apis.google.com adresinden hem HTTPS üzerinden hem de geçerli 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ırılmaya çalıştığında konsolda hata gösterilir.

Bu 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. düzeydeki diğer kaynak yönergeleri özetlenmiştir. 3. düzey spesifikasyon taslağı oluşturulmuştur, ancak ana tarayıcılarda büyük ölçüde kullanılmamaktadır.

base-uri

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

child-src

Çalışanların URL'lerini ve yerleştirilmiş çerçeve içeriklerini listeler. Örneğin child-src https://youtube.com, YouTube'dan video yerleştirmeyi etkinleştirir ancak diğer kaynaklardan video yerleştirmeyi sağlamaz.

connect-src

XHR, WebSockets ve EventSource'u kullanarak bağlanabileceğiniz kaynakları sınırlandırır.

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> etiketten gönderilmek 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ında kullanılamaz.

frame-src

Bu yönerge 2. seviyede kullanımdan kaldırılmış, ancak 3. seviyede geri yüklenmiştir. Bu etiket mevcut değilse tarayıcı child-src ürününe geri döner.

img-src

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

media-src

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

object-src

Flash ve diğer eklentiler üzerinde kontrol sağlar.

plugin-types

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

report-uri

Bir iç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

Bir sayfanın stil sayfalarını kullanabileceği kaynakları sınırlandırır.

upgrade-insecure-requests

Kullanıcı aracılarına, HTTP'yi HTTPS'ye değiştirerek URL şemalarını yeniden yazmalarını söyler. Bu yönerge, yeniden yazılması gereken çok sayıda eski URL'ye sahip web siteleri içindir.

worker-src

Çalışan, paylaşılan çalışan veya hizmet çalışanı olarak yüklenebilecek URL'leri kısıtlayan bir CSP Düzey 3 yönergesi. Temmuz 2017 tarihinden itibaren bu yönerge sınırlı sayıda uygulama almıştır.

Varsayılan olarak, belirli bir yönergeye sahip bir politika belirlemediğiniz sürece tarayıcı, ilişkili kaynağı kısıtlama olmadan herhangi bir kaynaktan yükler. Varsayılanı geçersiz kılmak için bir default-src yönergesi belirtin. Bu yönerge, -src ile biten belirtilmemiş tüm direktifler için varsayılan değerleri tanımlar. Örneğin, default-src öğesini https://example.com olarak ayarlarsanız ve bir font-src yönergesi belirtmezseniz yazı tiplerini yalnızca https://example.com içinden yükleyebilirsiniz.

Aşağıdaki yönergeler, yedek olarak default-src kullanmaz. Bunları ayarlamamanın herhangi bir şeye izin vermekle aynı şey 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 bunları, iki nokta üst üste ile ayrılmış yönergelerle birlikte HTTP üst bilgisinde listeleyin. Belirli bir türdeki gerekli tüm kaynakları tek bir yönergede 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 içerik yayınlama ağından yükleyen ve çerçeveli içerik veya eklenti kullanmayan bir web uygulaması):

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

Uygulama ayrıntıları

Modern tarayıcılar, öneksiz Content-Security-Policy üst bilgisini destekler. Bu, önerilen başlıktır. Online eğiticilerde görebileceğiniz X-WebKit-CSP ve X-Content-Security-Policy başlıkları kullanımdan kaldırılmıştır.

İGP, sayfa bazında tanımlanır. Korumak istediğiniz her yanıtla birlikte HTTP üstbilgisini göndermeniz gerekir. Bu sayede, belirli sayfalara yönelik politikalarda bu ihtiyaçlara göre ince ayar yapabilirsiniz. Örneğin, sitenizdeki sayfalardan birinde +1 düğmesi varken bazılarında yoksa düğme kodunun yalnızca gerektiğinde yüklenmesine izin verebilirsiniz.

Her yönergenin kaynak listesi esnektir. Kaynakları şemaya (data:, https:) göre veya yalnızca ana makine adı (example.com; bu ana makinedeki herhangi bir kaynak ile eşleşir: herhangi bir bağlantı noktası: herhangi bir bağlantı noktası) ile tam nitelikli bir URI'ye (https://example.com:443, yalnızca HTTPS, yalnızca example.com ve yalnızca 443 numaralı bağlantı noktasıyla eşleşen https://example.com:443) kadar bir aralıkta belirtebilirsiniz. Joker karakterler kabul edilir ancak yalnızca şema, bağlantı noktası veya ana makine adının en soldaki konumunda yer alır: *://*.example.com:*, herhangi bir bağlantı noktasında herhangi bir şema kullanarak example.com özelliğinin tüm alt alan adlarıyla eşleşir (ancak example.com ile eşleşmez).

Kaynak liste dört anahtar kelime de kabul etmektedir:

• 'none' hiçbir şeyle eşleşmiyor.
• 'self' geçerli 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çınma bölümüne bakın.
• 'unsafe-eval', eval gibi metin-JavaScript mekanizmalarına izin verir. Daha fazla bilgi için eval() kullanmaktan kaçının bölümüne bakın.

Bu anahtar kelimeler için tek tırnak işareti gerekir. Örneğin, script-src 'self' (tırnak işaretleriyle) mevcut ana makineden JavaScript'in yürütülmesini yetkilendirir; script-src self (tırnak işareti olmadan), "self" adlı bir sunucudan (ve mevcut ana makineden değil) JavaScript'e izin verir. Muhtemelen kastettiğiniz şey bu değildir.

Sayfalarınızı korumalı alana alın

Bahsetmeye değer bir yönerge daha var: sandbox. Sayfanın yükleyebileceği kaynaklar yerine, sayfanın yapabileceği işlemlere kısıtlamalar getirir. Bu nedenle, 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. Bunun sayfa üzerinde çok çeşitli etkileri olabilir: Sayfayı benzersiz bir kaynağa yönlendirme ve form gönderimini önleme vb. Biraz 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 iletim mekanizması bir HTTP başlığıdır. Bununla birlikte, bir sayfadaki politikanın doğrudan işaretlemede ayarlanması da yararlı olabilir. Bu işlemi http-equiv özellikli 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 öğe frame-ancestors, report-uri veya sandbox için kullanılamaz.

Satır içi kod kullanmaktan kaçının

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

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

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

şuna benzer:

<!-- 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 olmakla kalmaz, aynı zamanda web tasarımı en iyi uygulamalarıyla da uyumludur. Satır içi JavaScript, yapı ve davranışı kodu karmaşık hale getirecek şekillerde karıştırır. Önbelleğe almak ve derlemek de daha karmaşıktır. Kodunuzu harici kaynaklara taşımak, sayfalarınızın daha iyi performans göstermesini sağlar.

Ayrıca, sitenizi CSS tabanlı veri hırsızlığı 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ı 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çinde olması gerekiyorsa kullanın.

Satır içi komut dosyalarını ve stilleri, script-src veya style-src yönergesinde izin verilen kaynak olarak 'unsafe-inline' ekleyerek etkinleştirebilirsiniz. CSP Düzey 2, kriptografik tek seferlik rastgele sayı (bir kez kullanılır) veya aşağıdaki gibi karma oluşturma işlemi kullanarak izin verilenler listenize belirli satır içi komut dosyaları eklemenize olanak tanır.

Tek seferlik rastgele sayı kullanmak için komut dosyası etiketinize bir tek seferlik rastgele özellik verin. Değeri, güvenilir kaynaklar listesindeki 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>

script-src yönergenize, nonce- anahtar kelimesinin ardından tek seferlik rastgele sayı ekleyin:

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

Nonce'lar her sayfa isteği için yeniden oluşturulmalı ve tahmin edilemez olmalıdır.

Karmalar da benzer şekilde çalışır. Komut dosyası etiketine kod eklemek yerine, komut dosyasının bir SHA karmasını oluşturun ve bunu script-src yönergesine ekleyin. Örneğin, sayfanızda aşağıdaki ifadeler yer alıyorsa:

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

Politikanız şunları içermelidir:

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

sha*- öneki, karmayı oluşturan algoritmayı belirtir. Önceki örnekte sha256- kullanılsa da CSP, sha384- ve sha512- özelliklerini de destekler. Karma oluşturma işlemini oluştururken <script> etiketlerini çıkarın. Baştaki ve sondaki boşlukları da içeren, büyük harf kullanımı ve boşluklar önemlidir.

SHA karmaları oluşturmaya yönelik çözümler, istenen sayıda dilde kullanılabilir. Chrome 40 veya sonraki bir sürümünü kullanarak Geliştirici Araçları'nı açıp sayfanızı yeniden yükleyebilirsiniz. Konsol sekmesi, satır içi komut dosyalarınızın her biri için doğru SHA-256 karmasına sahip hata mesajlarını gösterir.

eval() kullanmaktan kaçının

Bir saldırgan doğrudan komut dosyası yerleştiremediğinde bile, giriş metnini yürütülebilir JavaScript'e dönüştürüp kendi adına yürütmesi için uygulamanızı kandırabilir. eval(), new Function(), setTimeout([string], …) ve setInterval([string], ...), saldırganların yerleştirilen metin aracılığıyla kötü amaçlı kod yürütmek için kullanabileceği vektörlerdir. CSP'nin bu riske karşı varsayılan yanıtı tüm bu vektörleri tamamen engellemektir.

Bunun, uygulama derlemeniz üzerinde aşağıdaki etkileri olur:

• JSON'u, eval kullanmak yerine yerleşik JSON.parse öğesini kullanarak ayrıştırmalısınız. Güvenli JSON işlemleri, IE8'den beri her tarayıcıda kullanılabilir.

• Dizeler yerine satır içi işlevleri kullanarak yaptığınız tüm setTimeout veya setInterval çağrılarını yeniden yazmanız gerekir. Örneğin, sayfanız aşağıdakileri içeriyorsa:

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

  Şöyle yeniden yaz:

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

• Çalışma zamanında satır içi şablonlar kullanmaktan kaçının. Birçok şablon kitaplığı, çalışma zamanında şablon oluşturmayı hızlandırmak ve bu sayede kötü amaçlı metnin değerlendirilmesini sağlamak için genellikle new Function() kullanır. Bazı çerçeveler, eval olmadığı için güçlü bir ayrıştırıcıya dönüşen ilk CSP'yi destekler. AngularJS'nin ng-csp yönergesi bunun için iyi bir örnektir. Ancak bunun yerine, Gidonlar gibi önceden derleme olanağı sunan bir şablon dili kullanmanızı öneririz. Şablonlarınızı önceden derlemeniz, kullanıcı deneyimini en hızlı çalışma zamanı uygulamasına kıyasla daha hızlı hale getirebilir ve sitenizi daha güvenli hale getirebilir.

eval() veya diğer text-to-JavaScript işlevleri uygulamanız için gerekliyse 'unsafe-eval' öğesini bir script-src yönergesinde izin verilen kaynak olarak ekleyerek etkinleştirebilirsiniz. Sunduğu kod yerleştirme riskinden dolayı bunu kesinlikle önermiyoruz.

Politika ihlallerini bildirme

Kötü amaçlı yerleştirmeye izin verebilecek hataları sunucuya bildirmek için, tarayıcıya bir report-uri yönergesinde belirtilen POST JSON biçiminde ihlal raporu bildirmesini 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"
    }
}

Rapor, politika ihlalinin nedenini bulma konusunda faydalı bilgiler içerir. 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 ettiği belirli yönerge (violated-directive) ve sayfanın tüm politikası (original-policy) bulunur.

Yalnızca Rapor

CSP'yi kullanmaya yeni başlıyorsanı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 üst bilgisi göndermek yerine bir Content-Security-Policy-Report-Only üst bilgisi 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 belirttiğiniz konuma ihlal raporları gönderir. Hatta bir politikayı izlerken diğerini izlemek için her iki üst bilgiyi de gönderebilirsiniz. Bu, mevcut politikanızı uygularken İGP'nizde yaptığınız değişiklikleri test etmenin harika bir yoludur: Yeni bir politika için raporlamayı etkinleştirin, ihlal raporlarını izleyin, hataları düzeltin ve yeni politikadan memnun olduğunuzda politikayı uygulamaya başlayın.

Gerçek Dünyadaki Kullanım

Uygulamanız için politika oluşturmanın ilk adımı, yüklediğiniz kaynakları değerlendirmektir. Uygulamanızın yapısını anladıktan sonra, şartlarını temel alan bir politika oluşturun. Aşağıdaki bölümlerde birkaç yaygın kullanım alanı ve bunların CSP yönergelerini uygulayarak desteklemeye yönelik karar süreci adım adım anlatılmaktadır.

Sosyal medya widget'ları

• Facebook'un Beğen düğmesi birkaç uygulama seçeneği içerir. Sitenizin geri kalanından korumalı alanda tutmak için <iframe> sürümünü kullanmanızı öneririz. Düzgün çalışması için bir child-src https://facebook.com yönergesi gerekir.
• X'in Tweet düğmesi, bir komut dosyasına erişime dayanır. 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 da benzer gereksinimleri vardır ve benzer şekilde ele alınabilirler. Bu kaynakları test etmek amacıyla 'none' için default-src ayarlamanızı ve hangi kaynakları etkinleştirmeniz gerektiğini belirlemek için konsolunuzu izlemenizi öneririz.

Birden çok 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

Evde kalma

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

Site, https://cdn.mybank.net adresindeki bir CDN'den tüm resimleri, stili ve komut dosyasını yüklüyor ve veri almak için XHR kullanarak https://api.mybank.com/ ağına bağlanır. Çerçeveleri kullanır ancak yalnızca sitedeki yerel sayfalar için kullanılır (üçüncü taraf kaynaklı değil). Sitede Flash yok, yazı tipi yok, ekstralar yok. 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üklendiğinden, ancak kodlama konusunda deneyimsiz olduğundan ve satır içi komut dosyaları ve stillerle dolu üçüncü taraf forum yazılımlarını yeniden yazacak kaynaklara sahip olmadığından emin olmak isteyen bir forum yöneticisine yönelik bir CSP örneği verilmiştir:

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

default-src öğesinde https: 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ın üzerine yazılır.

CSP standart geliştirme

İçerik Güvenliği Politikası Düzey 2, W3C için önerilen bir standarttır. W3C'nin Web Uygulaması Güvenliği Çalışma Grubu, spesifikasyonun bir sonraki yinelemesi olan İçerik Güvenliği Politikası Düzeyi 3'ü geliştirmektedir.

Yakında kullanıma sunulacak bu özelliklerle ilgili tartışmaları takip etmek için public-webappsec@ posta listesi arşivleri sayfasına göz atabilirsiniz.