What is a content security policy [Updated]?

What is a content security policy? It is a technique that provides an additional layer of protection for websites against certain types of security threat such as cross-site scripting attacks.

But you probably don’t have one.

So what do they do?

For many websites, especially ones that allow users to generate content, one of the biggest security threats is that a malicious user could somehow manage to upload and attach to webpages a script file that harvests details, spreads malware or otherwise damages your brand or users. Websites can typically restrict and filter the content submitted by users in order to mitigate the risk but the danger still exists that a malicious user will find an exploit or workaround.

A content security policy helps to lock down a site tightly. It establishes a white list of scripts, fonts and styles (among other assets) that may be included and executed on a website and blocks those that have not been given permission to run. What this means in practice is that if a malicious user manages to upload a script and include it in the page then web browsers displaying an infected page will see the script is not whitelisted and block its execution and any damage it may cause.

CSP policies can be difficult to design and implement, which is probably why you don’t have one. In the 2022 world of Software-as-a-service where JavaScript, Font and other files are being provided by third-party companies to be pasted in your website, keeping track of what permissions you grant and ensuring that the code you are importing doesn’t require too lax an environment to run can be a juggling act. But the threats now are such that the pain often outweighs the time necessary to configure a CSP.

CSP policies can be configured at the web server level (by adding code into an .htaccess file) they are more often added by using a plugin or package.

In WordPress plugins such as Content Security Plugin Manager (https://wordpress.org/plugins/csp-manager/) and WP Content Security Plugin (https://en-gb.wordpress.org/plugins/wp-content-security-policy/) are available to help add the headers needed for the CSP policies.

In Laravel the CSP package from Spatie (https://github.com/spatie/laravel-csp) is an easy one to install and configure, but as with the WordPress ones mentioned, the actual rules necessary will take some head scratching and thought.

So what do rules look like?

An article on Google (https://developers.google.com/web/fundamentals/security/csp) shows a typical rule.

Content-Security-Policy: script-src 'self' https://apis.google.com

This rule states that scripts can only have a src attribute containing a link to a file hosted on the same domain or on the apis.google.com domain can be executed on this site. If someone comes along and uploads a script calling out to another URL via an exploit now the CSP will block the script and report it has blocked it. In development this is usually to the developer console, but in a production environment you can usually set up to send a report to an external href.

CSP setup can be difficult (I’d go as far as to say a pain in the a***), but it can be worth it for the added piece of mind and security it gives you and your website.