Content-Security-Policy
Content Security Policy (CSP) is a HTTP header that tells complying browsers not to load or execute some things in a webpage. The presence of a well-formed, restrictive CSP header is taken as an indication of good site trustworthiness, according to some arbitrary metrics.
These resources provide a top-down view of CSP:
- Content Security Policy (CSP) [MDN] – a high-level summary, with some examples
- Content-Security-Policy [MDN] – a technical description of the CSP HTTP response header
- Content Security Policy Reference [content-security-policy.com] – a living quick reference guide of values, browser support, example configs, etc.
- Content Security Policy Level 2 [W3C] – the W3C work-in-progress draft for CSP v2
And also:
- Content Security Policy 1.0 [W3C] – the W3C Candidate Recommendation (i.e. not-quite-but-basically spec) for CSP v1.0
CSP is mostly useful if you don't trust the content of your pages; for example: if you operate a site where the content is created by unreliable clients (like a wiki or blog), or you include user-generated content (like comments.) Or if you want to get a high rank on the Mozilla observatory. My feeling is that its applicability depends on your site fitting one of two use-cases:
Fully Self-Contained Sites
(or sites with a well-defined and restricted set of external dependencies)
If you are running a site that contains all its own images, styles, and scripts – or you have a very specific set of external dependencies – it is easy to set up a site-wide CSP. In this case a blanket policy like default-src 'self' can usually apply.
Sites with Dynamically Generated Content
(which can tune the response headers specifically for each page/resource)
If you have the opportunity to construct response headers individually – for example, if your pages are all dynamically generated – it can be (relatively) straight-forward to generate a CSP tailored to each page. This still requires a high level site-wide policy to be in place, but the fine details can be tuned; for example, only allowing externally-linked resources on pages that are known to require them.
Dynamically-generated resources also introduce the possibility of using nonces to whitelist certain approved resources (under CSP v2.)
In any case, take heed of this sentence in the introductions of the W3 specs: "There is often a non-trivial amount of work required to apply CSP to an existing web application." It is not a turn-key or plug-in option. To help site maintainers migrate to CSP there exists the Content-Security-Policy-Report-Only header, which is exactly the same as the CSP header except that violations will not be blocked by the browser, and will instead be reported. Any deployed CSP should include a report-uri directive, both to help detect misconfigurations and to help diagnose actual attacks.
Footnotes:
- A bit of presumptuous idealism from Mozilla: "...CSP is mandatory for all new websites..." [1]
Update [2017-03-03]
Some updated links
- https://w3c.github.io/webappsec-csp/ – the W3C work-in-progress draft for CSP v3, which uses...
- https://wicg.github.io/reporting/ – the W3C work-in-progress draft for reporting, which is used in CSPv3's new "report-to" directive as a replacement for the old "report-uri"
This introduces another cost for supporting CSP: it's changing so frequently that old versions don't even have a chance to become standardised before the next version is implemented in browsers and released. Watch for back-compat issues if you're planning on using CSP.