Content Security Policy

CSP – The how and why of a Content Security Policy

by Kenneth Linzey on 18-Jun-2018

Recently we've recommended to more and more of our customers that they set up a Content Security Policy alongside the usual security headers. In this blog we dive deeper into that topic: where does this new standard originate from? Why would you like to use one? How do you set one up? And how does CSP relate to other, similar standards?

Where does this new standard originate from and why would you like to use one?

CSP is developed by the World Wide Web Consortium (W3C), the main international standards organization for the World Wide Web. CSP is a new standard that allows developers to define restrictions on the behaviour of a website or application. For example: from which external locations is it allowed to load scripts, stylesheets or images? Is the browser allowed to load the website in an iframe from a different website?

A well-adjusted CSP can prevent multiple attacks and vulnerabilites such as cross-site scripting (XSS) or clickjacking from happening.

How do you set up a CSP?

Webservers can add a special header named Content-Security-Policy to every response. For example, this website has set the following header:

Content-Security-Policy: default-src; script-src 'none'; frame-ancestors 'none'; block-all-mixed-content; report-uri /csp-violations/;

What's the meaning of the attributes?

It's possible to define a lot of attributes within the CSP header. Please refer to this source for a complete and up-to-date overview of the attributes. We will highlight the most important ones:

You can also use the CSP to enforce that resources can only ever be loaded using HTTPS by adding the https:// protocol to every value defined for the *-src attributes. This prevents resources from being loaded over non-encrypted HTTP connections. The same effect can be achieved by adding the attribute block-all-mixed-content.

CSP can also be used to restrict a couple of bad habits:

This enforces the best practice to have scripts and CSS in separate files referenced by HTML pages. If your site needs to allow it, the CSP can be set to do that using keywords like 'unsafe-eval' and 'unsafe-inline'.

How do you configure a CSP?

A CSP can be defined in several ways, for example in the web server configuration, or using PHP. We recommend to first apply a Content-Security-Policy-Report-Only header. This header will not block violations but only report them. This allows you to first define a CSP header, then calmly browse the website and handle CSP violations without impacting website functionality. One could use the following header as a starting point:

Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self'; report-uri;

Every time a requested resource violates the CSP, the browser will make a POST request to the URL specified within the report-uri of the CSP including details of the violation. It's important to keep track of these violations. On the one hand you would want to know when the CSP is unnecessarily blocking resources. On the other hand you would want to know when somebody is trying to inject resources into your website, perhaps an attacker or malicious user. If you already have a good idea what your CSP should look like, it's also possible to generate a CSP using this website.

How does CSP relate to other standards?

SubResource Integrity (SRI) is a standard that complements CSP. SRI only allows trusted and familiar resources from third-party-providers to be loaded by the browser. More and more browsers are starting to support SRI. It works like this:

Using CSP you can enforce the use of SRI using the attribute 'require-sri-for' with the values script or style.

If you have any questions about or need technical assistance securing your website or application using a Content Security Policy? You can find more information online at, and you can always contact us – we're happy to help!

Feedback welcome!

IT Security | Testing | Advice