İç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.
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.
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çineval()
'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
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şikJSON.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
veyasetInterval
ç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 veeval
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çinchild-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.