Thanks to Content Security Policy, you can protect your website from numerous vulnerabilities concerning content injection. Let’s see why and how to use that simple but powerful HTTP header, now widely supported by web browsers.
XSS vulnerabilities (Cross-Site Scripting), that allow attackers to inject malicious scripts in a web page, rank at the third place of the most critical web application security flaws provided by the renowned OWASP community (Open Web Application Security Project). Those script injections in a web page can lead to session hijacking or website defacing for example.
To prevent from these kind of attacks, it is required to control all data coming from users before storing or using them on a web page. Nevertheless, even assuming all the protections are set up by your side, you will still be relying on third party content, as your providers could be attacked too!
Good news! Content Security Policy permits you to add an extra security layer and to control very precisely what kind of content you allow on your web pages!
If you’re not convinced yet about the benefit from using Content Security Policy, here’s a shortlist of major websites doing so: Facebook, Twitter, Github, toysrus.com, letsencrypt.org …
How Content Security Policy (CSP) works
CSP is nothing more than an HTTP header sent to users by your web server. This header lets you define your own security policy that will rule content on your web page. This policy will be enforced by the web browser, that will ignore disallowed content (also resulting in a warning message within the browser console).
Here is a simple example of a CSP header:
Content-Security-Policy: "default-src 'self'; script-src 'self' https://ajax.googleapis.com"
How can we read this?
“Default-src” sets the default policy for all kinds of content (all the “xxx-src” directives), except if overriden . The “self” value whitelists all the content coming from the same domain (and same port and URL scheme).
“Script-src” brings a more specific policy about the scripts. In this case, scripts provided by the Google’s CDN are allowed as those from the current domain (with the “self” value).
As a consequence, with such a CSP, a style sheet coming from https://ajax.googleapis.com would be rejected by the browser, as the default-src policy rules all the styles.
In the second part of this article (How to implement Content Security Policy), you will find the list of the available CSP directives, with the most common values to use.
Beware of the CSP limits
Unfortunately, CSP is not a cure-all: it prevents your website from the consequences of an attack, but not from the attack itself! (if there is an XSS vulnerability, a script could still be injected, however the web browser would not run it).
To be efficient, this security policy has to be enforced by the browser, and so CSP has to be supported by him… That is not the case of older web browsers – as Internet Explorer 8 for example.
Still about support considerations: please note that there are several versions of CSP. So take time to check the compliance of the directives you are about to use. Information about CSP support by the browsers can be found on this Can I Use page.
The third version of CSP is still in draft mode (see the W3C working draft), and we can notice through these 3 first versions some modifications without backward compatibility . Even if in most of the cases, it won’t cause major troubles, please keep in mind that CSP is a quite new technology, still not widespread. This could be a problem if you’re targeting advanced and specific use cases.
Another point to consider: CSP is really efficient if the policy you set is strongly restrictive. If your website is particularly complex, frequently updated or based on numerous third-party content, you will probably have to make choices between difficult maintenance and permissive security policy…
CSP: about security but not only
Thanks to CSP, you can choose the content that are allowed on your webpage and those that will be blocked. As a consequence, it is an excellent tool to keep the control of your web pages’ content… even it is not a question of security. It is, indeed a good way to ensure that a third-party provider would not start loading dozens of unexpected files in your web page!
With a restrictive policy you may protect some of your users from malwares or indelicate ISPs injecting content within your web pages (here is an example with a hotspot)! Moreover, who knows? You could protect users from themselves, as this Facebook warning about Self-XSS reminds it.
Another unexpected side-effect could occur with CSP: this time it concerns some bookmarklets or “gentle” browser extensions that may need to interact with a CSP protected page. Beside, Nicolas Hoffman gathered a list of unexpected errors with CSP.
Now it is to time to start with the second chapter of this article : How to implement Content Security Policy?