Content Security Policy
The standard, originally named Content Restrictions, was proposed by Robert Hansen in 2004, 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 and quickly with further versions (Level 2) published in 2014. As of 2015[update] draft of Level 3 is being developed with the new features being quickly adopted by the web browsers.
The following header names are in use as part of experimental CSP implementations:
Content-Security-Policy— standard header name proposed by the W3C document. Google Chrome supports this as of version 25. Firefox supports this as of version 23, released on 6 August 2013. WebKit supports this as of version 528 (nightly build).
X-WebKit-CSP— deprecated, experimental header introduced into Google Chrome and other WebKit-based browsers (Safari) in 2011.
X-Content-Security-Policy— deprecated, experimental header introduced in Gecko 2 based browsers (Firefox 4 to Firefox 22, Thunderbird 3.3, SeaMonkey 2.1).
A website can declare multiple CSP headers, also mixing enforcement and report-only ones. Each header will be processed separately by the browser.
A number of web application frameworks support CSP, for example AngularJS (natively) and Django (middleware). Instructions for Ruby on Rails have been posted by 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.
- Mixed Content, to clarify the intended browser's policy on pages loaded over HTTPS and linking content over plaintext HTTP
- Upgrade Insecure Requests, hinting browsers on how to handle legacy links on pages migrated to HTTPS
- Referrer Policy, CSP extension to hint the browser on generation of the Referer headers.
In December 2015 a method of bypassing
Mode of operation
- Inline CSS statements
styleattributed to HTML elements
- string arguments for
- Dynamic CSS statements
<script src>), parse JSON instead of evaluating it and use
EventTarget.addEventListener() to set event handlers.
- This behavior can be disabled globally by a special
- Trusted inline
<style>blocks can individually whitelisted in the CSP using
- This behavior can be disabled globally by a special
- For example, AngularJS requires only one initialization flag to be switched into the CSP-compatible mode —
<html ng-app ng-csp>
Browser add-ons and extensions exemption
According to the CSP Processing Model, CSP should not interfere with the operation of browser add-ons or extensions installed by the user. This feature of CSP effectively allows any add-on or extension to inject script into web sites, regardless of the origin of that script, and thus be exempt to CSP policies. The W3C Web Application Security Working Group considers such script to be part of the Trusted Computing Base implemented by the browser; however, it has been argued to the working group by a representative of Cox Communications that this exemption is a potential security hole that could be exploited by malicious or compromised add-ons or extensions.
- NoScript – anti-XSS protection and Application Boundaries Enforcer (ABE), extension for Firefox
- HTTP Switchboard – user defined CSP rules, extension for Google Chrome and Opera
- HTTP Strict Transport Security
- HTTP Public Key Pinning
- Sid Stamm (2009-03-11). "Security/CSP/Spec - MozillaWiki". wiki.mozilla.org. Retrieved 2011-06-29.
Content Security Policy is intended to help web designers or server administrators specify how content interacts on their web sites. It helps mitigate and detect types of attacks such as XSS and data injection.
- "State of the draft". 2011-11-30. Retrieved 2011-12-30.
- "Can I use Content Security Policy?". Fyrd. Retrieved February 22, 2013.
- Robert Hansen (2009-06-01). "Mozilla's Content Security Policy". Archived from the original on March 18, 2015. Retrieved 2011-06-29.
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.
- "Content Security Policy 1.0". W3C. Retrieved 2015-11-13.
- "Content Security Policy Level 3". W3C. Retrieved 2015-11-13.
- "Chrome 25 Beta: Content Security Policy and Shadow DOM". Google. January 14, 2013. Retrieved February 22, 2013.
- "Content Security Policy 1.0 lands in Firefox Aurora". Mozilla Foundation. May 29, 2013. Retrieved June 16, 2013.
- "RapidRelease/Calendar". Mozilla Foundation. May 29, 2013. Retrieved June 16, 2013.
- "Bug 96765 - Implement the "Content-Security-Policy" header". WebKit. October 31, 2012. Retrieved August 7, 2015.
- "New Chromium security features, June 2011". Google. June 14, 2011. Retrieved February 22, 2013.
- "Introducing Content Security Policy". Mozilla Foundation. Retrieved February 22, 2013.
- "HTML META element". Content Security Policy Level 2. W3C. Retrieved 2015-11-14.
- "Defense in Depth: Locking Down Mash-Ups with HTML5 Sandbox". Windows Internet Explorer Engineering Team. Retrieved April 13, 2014.
- "ngCsp directive". AngularJS.
- "Content security policy". GitHub.
- "Web Application Security Working Group". Retrieved 2015-11-13.
- "CSP 2015". XSS Jigsaw. Retrieved December 12, 2015.
- "An Abusive Relationship with AngularJS". Retrieved January 5, 2016.
- West, Mike (June 15, 2012). "An Introduction to Content Security Policy". HTML5 Rocks. Retrieved February 22, 2013.
- For example in Django a CSP receiver is available in django-security module.
- "Content Security Policy Builder".
- "Content Security Policy Reporting". report-uri.io. Scott Helme.
- "CSP Processing Model". 2012-11-15. Retrieved 2013-10-06.
- "Subverting CSP policies for browser add-ons (extensions).". 2013-09-25. Retrieved 2013-10-06.
- "Re: [CSP] Request to amend bookmarklet/extensions sentence in CSP1.1". 2014-08-03. Retrieved 2015-10-08.