İç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.
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.
![Konsol hatası: 'http://evil.example.com/evil.js' komut dosyasının yüklenmesi, şu İçerik Güvenliği Politikası yönergesini ihlal etmesi nedeniyle reddedildi: script-src 'self' https://apis.google.com](https://web.dev/static/articles/csp/image/console-error-refused-l-fc9682b801661.png?authuser=5&hl=tr)
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çineval()
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
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şikJSON.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
veyasetInterval
ç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 birchild-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çindefault-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.