Content Security Policy (CSP) Explained

Category: Web Security Readings - Last Updated: Fri, 26 Jul 2019 - by Netsparker Security Team

The Content Security Policy (CSP) standard is a way to selectively specify which content should be loaded in web applications. This can be done by whitelisting specific origins, using nonces or hashes.

Content Security Policy (CSP) Explained

How Does Content Security Policy Work?

As a developer you can specify the Content Security Policy through a HTTP response header called Content-Security-Policy. Then a web browser that supports CSP, such as Chrome or Firefox, parses the header information and determines which sources are trusted or not based on the instruction sent in the header. This is basically a whitelist approach which may consist of instructions like self (allowing inline scripts), specific domains, nonces or hashes that have to be present and valid in order for the content to be loaded.

What kinds of Web Application Vulnerabilities can CSP Prevent?

CSP can prevent cross-site scripting vulnerabilities, clickjacking, mixed content security issues, protocol downgrading and any other kind of code injection which is the result of the injection of untrusted content into a trusted resource. Below are a few basic examples of the different methods you can use to implement Content Security Policy in your web applications:

Whitelisting of Domains

This is an example of a whitelist allowing inline scripts and all scripts loaded from

Content-Security-Policy: script-src 'self'

Even though domain whitelisting sounds like a good idea be careful when using it because if attackers manage to gain unauthorized access to the web application's code they can  include outdated libraries (e.g. on a trusted CDN), or abuse open redirects or a JSONP callback. This should only be done on trusted domains, preferably controlled by the site owner.

Using Nonces

A nonce (a number that is used only once) is similar to CSRF token but for specific resources. It is activated by using nonce-$random_value in the HTTP response header such as in the example below:

Content-Security-Policy: script-src 'self' 'nonce-bmV0c3BhcmtlciBydWxlcyA7KQ=='

The nonce should be a random string, generated with a cryptographically secure function to make sure it is not predictable, as this would render it useless. The idea behind a nonce in Content Security Policy is that it is a value that is impossible for the attacker to know, but is known and set by the developer. It has to be refreshed on every new page load. The developer has to add the nonce to the resource he wants to load. E.g.

<script nonce="bmV0c3BhcmtlciBydWxlcyA7KQ==">
     var a = 'b';

The reason behind adding the nonce to the script call is that with the above CSP setting all script blocks without a nonce are not executed. If an attacker manages to insert a script block into the page, he can't know the nonce as it is randomly generated on every page call. Therefore the injection will have no effect on the user.


Content Security Policy can also be configured to only load resources if they match defined hashes. That way it's not possible to execute resources that have been tampered with. To set such a hash the following CSP header can be used:

Content-Security-Policy: script-src 'self' 'sha256-78iKLlw3hSqddlf6qm/PGs1MvBzpvIEWioaoNxXIZwk='

This contains the hash of the following script block


The developer creates the hash and implement the CSP rule with the following PHP code:

header("Content-Security-Policy: script-src 'self' 'sha256-".base64_encode(hash('sha256', 'alert("allowed");', true))."'");

The advantage of such a hash is that it only has to be generated once to offer good protection. It also offers protection against tampering with the script while a simple domain whitelist can't guarantee that.

How to activate Content Security Policy

As explained earlier, Content Security Policy can be activated by using HTTP response headers or html meta elements, which then the visitor's browser parses to enforce the rules the developer has set. If the HTTP headers are the same for every page, then you can configure them at web server level. If the HTTP headers are different for every page or on every reload, such as when using nonce or hask then they have to be generated at web application level.

The HTTP header format is simple. The header itself is called Content-Security-Policy and in it you specify the instructions for the browser as per the example below:

Content-Security-Policy: script-src 'self'

Below is an example of how to enable Content Security Policy via a HTML meta tag:

<meta http-equiv="Content-Security-Policy" content="default-src 'self'; child-src 'none'; object-src 'none'">

Example of a Content Security Policy (CSP) Rule

Below is an example of a Content Security Policy rule to only allow scripts that have the following nonce "bmV0c3BhcmtlciBydWxlcyA7KQ==":

Content-Security-Policy: script-src 'self' 'nonce-bmV0c3BhcmtlciBydWxlcyA7KQ=='

<script nonce=bmV0c3BhcmtlciBydWxlcyA7KQ==>

     console.log("code works")

The above rule is sent using an HTTP response header or a meta element. Of course the nonce has to be random and must not be reused. As mentioned above external scripts are only included if the nonce is present in the script tag they are called with. If it doesn't match or there is no nonce the script will not be loaded or executed.

Check the Implementation of the Content Security Policy on your Web Applications Automatically with Netsparker

The Netsparker web application security scanners will automatically check the Content Security Policy (CSP) implemention on your web applications and will alert you if something is not implemented properly as per the below screenshot.

Netsparker web scanners report any possible issues with the implementation of the Content Security Policy

Demo of Content Security Policy

Slides for Content Security Policy Presentation & Demo

Here are the slides Sven used during the presentation and demo of the Content Security Policy.


Keep up with the latest web security
content with weekly updates.