İç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

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, 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 verilen ve verilmeyen içerikler hakkında müşteriye bilgi vermek için izin verilenler listelerini kullanın.
• Hangi yönergelerin kullanılabileceğ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ı ile üçüncü taraflarca kötü amaçlı olarak yerleştirilen komut dosyası arasındaki farkı 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ı, kaynağı ne olursa olsun sayfanın istediği kodları memnuniyetle indirir ve yürütür.

CSP'nin Content-Security-Policy HTTP başlığı, 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ı 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 bir dizi ayrıcalığı 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, WebSockets ve EventSource'u kullanarak bağlanabileceğiniz kaynakları sınırlar.

font-src

Web yazı tipleri 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ı kısıtlar.

object-src

Flash ve diğer eklentiler üzerinde kontrol olanağı 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öndereceğ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

Çalışan, paylaşılan çalışan veya hizmet çalışanı olarak yüklenebilen URL'leri kısıtlayan bir CSP Düzey 3 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ı 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'ü https://example.com olarak ayarlar ve bir font-src yönergesi belirtmezseniz yalnızca https://example.com'ten 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ğından yükleyen ve çerçevelenmiş içerik veya eklentiler kullanmayan bir web uygulaması için yönergeler verilmiştir:

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ğiticilerde görebileceğiniz X-WebKit-CSP ve X-Content-Security-Policy başlıkları kullanımdan kaldırılmıştır.

CSP sayfa bazında tanımlanır. Korumak istediğiniz her yanıtla birlikte HTTP üst bilgisini 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, o ana makinedeki her kaynakla eşleşen şema, herhangi bir bağlantı noktası) veya tam nitelikli bir URI'ye (https://example.com:443, yalnızca HTTPS ile eşleşen, yalnızca example.com ve yalnızca bağlantı noktası 443) kadar belirlilik içerecek şekilde belirtebilirsiniz. Joker karakterler yalnızca bir şema, bağlantı noktası veya ana makine adının en soldaki konumunda kabul edilir. *://*.example.com:*, herhangi bir bağlantı noktasında herhangi bir şema kullanılarak example.com alanının tüm alt alan adlarıyla (example.com kendisi değil) eşleşir.

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 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 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. Bunun sayfa üzerinde çok çeşitli etkileri olabilir: sayfayı benzersiz bir kaynağa zorlamak ve form göndermeyi önlemek. 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. Bununla birlikte, bir sayfada doğrudan işaretlemede 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 kadar güçlü olsalar da XSS saldırılarının ortaya çıkardığı en büyük tehdidi çözemezler: satır içi komut dosyası yerleştirme. Bir saldırgan, doğrudan kötü amaçlı yük (<script>sendMyDataToEvilDotCom()</script> gibi) içeren bir komut dosyası etiketi yerleştirebilir. Bu durumda tarayıcı, bu etiketi geçerli bir satır içi komut dosyası etiketinden ayırt edemez. 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, aynı zamanda satır içi etkinlik işleyicileri ve javascript: URL'leri de içerir. script etiketlerinin içeriğini harici bir dosyaya taşımanız ve javascript: URL'leri ile <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 şekilde değiştirebilirsiniz:

<!-- 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 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 edilemez olmalıdır.

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ız şunları içermelidir:

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

sha*- ön eki, karmayı oluşturan algoritmayı belirtir. Önceki örnekte sha256- kullanılmıştır ancak CSP, sha384- ve sha512- özelliklerini de destekler. Karma oluşturma işlemi sırasında <script> etiketlerini atlayın. Baştaki ve sondaki boşluklar dahil olmak üzere büyük harf ve boşluk kullanımı.

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 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ı, bu vektörlerin tümünü tamamen engellemektir.

Bunun uygulama oluşturma şekliniz üzerinde aşağıdaki etkileri olur:

• 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şturmayı 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. Ancak bunun yerine, önceden derleme sunan Gidon çubukları gibi bir şablon 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. Oluşturduğu kod yerleştirme riski nedeniyle bunu kesinlikle önermiyoruz.

Politika ihlallerini bildirme

Kötü amaçlı yerleştirmeye izin verebilecek hataları sunucuya bildirmek için tarayıcıya, report-uri yönergesinde belirtilen bir konum için JSON biçimli POST ihlal raporu göndermesini bildirebilirsiniz:

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 bulmayla ilgili yararlı bilgiler yer alır. Bu bilgiler arasında ihlalin gerçekleştiği sayfa (document-uri), söz konusu sayfanın referrer özelliği, sayfanın politikasını ihlal eden kaynak (blocked-uri), ihlal ettiği 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ığınızda gereksinimlerine dayalı 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ı bir alanda 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 örnek, her şeyi engelleyen varsayılan bir politikayla başlayarak bir bankacılık sitesi için bir İGP geliştirmektedir (default-src 'none').

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'

default-src içinde 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 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.