Content Security Policy

The standard, originally named Content Restrictions, was proposed by Robert Hansen in 2004,{{cite web|url=http://ha.ckers.org/blog/20090701/mozillas-content-security-policy/ |author=Robert Hansen |date=2009-06-01 |title=Mozilla's Content Security Policy |access-date=2011-06-29 |quote=Content Restrictions - a way for websites to tell the browser to raise their security on pages where the site knows the content is user submitted and therefore potentially dangerous. |url-status=dead |archive-url=https://web.archive.org/web/20150318224529/http://ha.ckers.org/blog/20090701/mozillas-content-security-policy/ |archive-date=March 18, 2015 }} first implemented in Firefox 4 and quickly picked up by other browsers. Version 1 of the standard was published in 2012 as W3C candidate recommendation{{cite web | url=http://www.w3.org/TR/2012/CR-CSP-20121115/ | title=Content Security Policy 1.0 | publisher=W3C | access-date=2015-11-13}} and quickly with further versions (Level 2) published in 2014. {{As of|2023}}, the draft of Level 3 is being developed with the new features being quickly adopted by the web browsers.{{cite web | url=https://w3c.github.io/webappsec-csp/ | title=Content Security Policy Level 3 | publisher=W3C | access-date=May 5, 2023}}

The following header names are in use as part of experimental CSP implementations:{{cite web | url=http://caniuse.com/contentsecuritypolicy | title=Can I use Content Security Policy? | publisher=Fyrd | access-date=February 22, 2013}}

• Content-Security-Policy – standard header name proposed by the W3C document. Google Chrome supports this as of version 25.{{cite web | url=https://blog.chromium.org/2013/01/content-security-policy-and-shadow-dom.html | title=Chrome 25 Beta: Content Security Policy and Shadow DOM | publisher=Google | date=January 14, 2013 | access-date=February 22, 2013}} Firefox supports this as of version 23,{{cite web | url=https://hacks.mozilla.org/2013/05/content-security-policy-1-0-lands-in-firefox-aurora/ | title=Content Security Policy 1.0 lands in Firefox Aurora | publisher=Mozilla Foundation | date=May 29, 2013 | access-date=June 16, 2013}} released on 6 August 2013.{{cite web | url=https://wiki.mozilla.org/RapidRelease/Calendar | title=RapidRelease/Calendar | publisher=Mozilla Foundation | date=May 29, 2013 | access-date=June 16, 2013}} WebKit supports this as of version 528 (nightly build).{{cite web | url=https://bugs.webkit.org/show_bug.cgi?id=96765 | title=Bug 96765 - Implement the "Content-Security-Policy" header | publisher=WebKit | date=October 31, 2012 | access-date=August 7, 2015}} Chromium-based Microsoft Edge support is similar to Chrome's.{{cite web | url=https://docs.microsoft.com/en-us/microsoft-edge/extensions-chromium/store-policies/csp | title=Content Security Policy (CSP) | publisher=Microsoft | access-date=February 6, 2020}}
• X-WebKit-CSP – deprecated, experimental header introduced into Google Chrome, Safari and other WebKit-based web browsers in 2011.{{cite web | url=https://blog.chromium.org/2011/06/new-chromium-security-features-june.html | title=New Chromium security features, June 2011 | publisher=Google | date=June 14, 2011 | access-date=February 22, 2013}}
• X-Content-Security-Policy – deprecated, experimental header introduced in Gecko 2 based browsers (Firefox 4 to Firefox 22, Thunderbird 3.3, SeaMonkey 2.1).{{cite web | url=https://developer.mozilla.org/en-US/docs/Security/CSP/Introducing_Content_Security_Policy | title=Introducing Content Security Policy | publisher=Mozilla Foundation | access-date=February 22, 2013}}

A website can declare multiple CSP headers, also mixing enforcement and report-only ones. Each header will be processed separately by the browser.

CSP can also be delivered within the HTML code using a meta tag, although in this case its effectiveness will be limited.{{cite web | url=http://www.w3.org/TR/CSP2/#delivery-html-meta-element | title=HTML META element | publisher=W3C | work=Content Security Policy Level 2 | access-date=2015-11-14}}

Internet Explorer 10 and Internet Explorer 11 also support CSP, but only sandbox directive, using the experimental X-Content-Security-Policy header.{{cite web | url=http://blogs.msdn.com/b/ie/archive/2011/07/14/defense-in-depth-locking-down-mash-ups-with-html5-sandbox.aspx | title=Defense in Depth: Locking Down Mash-Ups with HTML5 Sandbox | publisher=Windows Internet Explorer Engineering Team | access-date=April 13, 2014}}

A number of web application frameworks support CSP, for example AngularJS{{cite web |url=https://docs.angularjs.org/api/ng/directive/ngCsp |title=ngCsp directive | publisher=AngularJS | access-date=October 27, 2020}} (natively) and Django (middleware).{{cite web |url=https://github.com/sdelements/django-security |title=django-security|website=GitHub |date=21 November 2022 }} Instructions for Ruby on Rails have been posted by GitHub.{{cite web |url=https://github.com/blog/1477-content-security-policy |title=Content security policy |date=19 April 2013 |publisher=GitHub}} Web framework support is however only required if the CSP contents somehow depend on the web application's state—such as usage of the nonce origin. Otherwise, the CSP is rather static and can be delivered from web application tiers above the application, for example on load balancer or web server.

In December 2015{{cite web|url=http://blog.innerht.ml/csp-2015/|title=CSP 2015|date=23 November 2015|publisher=XSS Jigsaw|access-date=December 12, 2015|archive-date=20 December 2015|archive-url=https://web.archive.org/web/20151220222214/http://blog.innerht.ml/csp-2015/|url-status=dead}} and December 2016,{{Cite web|url=http://sebastian-lekies.de/csp/bypasses.php|title=Collection of CSP bypasses|last=Lekies|first=Sebastian|access-date=2017-06-05}} a few methods of bypassing 'nonce' allowlisting origins were published. In January 2016,{{cite web|url=http://www.slideshare.net/x00mario/an-abusive-relationship-with-angularjs|title=An Abusive Relationship with AngularJS|date=12 December 2015 |access-date=January 5, 2016}} another method was published, which leverages server-wide CSP allowlisting to exploit old and vulnerable versions of JavaScript libraries hosted at the same server (frequent case with CDN servers). In May 2017{{Citation|last=OWASP|title=AppSec EU 2017 Don't Trust The DOM: Bypassing XSS Mitigations Via Script Gadgets by Sebastian Lekies|date=2017-05-25|url=https://www.youtube.com/watch?v=p07acPBi-qw|access-date=2017-06-05}} one more method was published to bypass CSP using web application frameworks code.

File:ContentSecurityPolicy3 diagram.png

If the Content-Security-Policy header is present in the server response, a compliant client enforces the declarative allowlist policy. One example goal of a policy is a stricter execution mode for JavaScript in order to prevent certain cross-site scripting attacks. In practice this means that a number of features are disabled by default:

• Inline JavaScript code{{efn|name=fn1}}