What is Content Security Policy (CSP)?

Content Security Policy (CSP) is a browser security feature that was implemented to mitigate against certain types of browser-based attacks, like cross-site scripting. The CSP was standardized by the World Wide Web Consortium (W3C), and allows a website to send a set of rules (via HTTP headers or <meta> tags) that instruct the browser which sources of content are allowed. These rules, called directives, specify approved origins for scripts, images, styles, iframes, and more. The primary purpose of using CSP is to have full control of where scripts are loaded from, along with controlling which scripts a page is permitted to execute, thus attempting to prevent injected or unauthorized scripts from running.

For example, a CSP directive might say that scripts should only load from the site’s own domain (done by using ‘self’), or specific trusted domains. The browser will then try and block any script file or inline script that’s not from an allowed source, providing a crucial defense against XSS attacks where an attacker tries to inject malicious <script> tags or code into a site.

How CSP Works

A Content Security Policy is delivered to a website via an HTTP response header named `Content-Security-Policy`, or via a meta in the HTML body. The policy consists of directives separated by semicolons, and each directive is controlling a certain type of resource.

• ‘script-src’ self allows scripts only from the same origin of the domain. Any <script> from other domains (or inline script code) would be blocked by the browser.
• ‘connect-src’ self api.domain.com allows AJAX/XHR/fetch calls only to the same site, or to the trusted domain api.domain.com. This can be used to prevent malicious code from exfiltrating data to unknown servers from the site.
• img-src 'self' data: can be used to only load images from the same site and block external images - which can be used to prevent data leaks via image requests.

There are multitudes of other directives that can be used for other data types like media, fonts, iframes, etc. but the core idea of using a Content Security Policy is to whitelist trusted sources. When the browser loads a page and asks what content to load, it will first refer to the CSP and enforce these rules on every load. Any script or resource that loads this policy won’t be loaded.

How a CSP can Protect a Website

Mitigation of XSS attacks: In a cross-site scripting attack, or XSS attack, an attacker generally finds a way to inject and execute malicious JavaScript code into your page (like on an unsanitized input). By default, a CSP will block any inline scripts from executing on the page, unless a policy directive explicitly allows it. This means an attacker that injects something like `<script>evilCode()</script>` into a page, it won’t execute (unless ‘unsafe-inline’ is disallowed in the CSP!)

Blocking unauthorized third-party scripts: Many sites have third-party scripts for things like analytics, user tracking, and advertisements. With a CSP, site owners can limit which external sites can actually deliver scripts. For example, if you’re only looking to serve content from `analytics.example.com` and not anything else from example.com, your site’s CSP script-src directive can explicitly allow only that.

Preventing data exfiltration: As previously mentioned, a CSP can restrict actions on a page that can be used to stop malicious JavaScript code from sending data back to an attacker controlled domain. Using the `connect-src` directive blocks network requests to unauthorised servers, and can be used in combination with the `form-action` directive to ensure the data is only being sent to your domain. 

Enforce safe browsing practices: A CSP has directives to enforce safe behaviors that improve your site’s security in general. One example of this is `upgrade-insecure-requests`, which forces the browser to load all resources over HTTPS, preventing mixed and insecure content issues. Another directive is `frame-ancestors`, which can prevent clickjacking attacks by disallowing your page to be embedded in an attacker-controlled frame. 

Using a Content Security Policy can provide a strong baseline for your site’s security, but as highlighted in our post “Why Content Security Policy Doesn’t Work”, it isn’t an end-all-be-all solution for your site. Policies can drift, and allowlists can’t see into the code that’s being run. Pairing a CSP with an active client-side proxy like c/side to add real-time inspection and blocking to third-party scripts on your site gives you a great layer of defense, with peace of mind for your customers.