Why use the Content Security Policy?

The primary benefit of CSP is preventing the exploitation of cross-site scripting vulnerabilities. When an application uses a strict policy, an attacker who finds an XSS bug will no longer be able to force the browser to execute malicious scripts on the page. The policy only allows scripts with the correct nonce value generated on the server, which attackers cannot guess, so they cannot inject their own scripts - subject to some caveats discussed in the FAQ.

This is important because XSS bugs have two characteristics which make them a particularly serious threat to the security of web applications:

• XSS is ubiquitous. Cross-site scripting has consistently been listed as one of the most common flaws in web applications; almost all large applications have suffered from XSS in the past. This one type of flaw consistently accounts for over 60% of payouts under Google's Vulnerability Reward Program.
• XSS is damaging. An attacker who exploits such a bug and executes JavaScript in the context of another user's session gets full access to their data in the vulnerable application, and in all other applications hosted in the same domain. In many cases the attacker can compromise the account and retain persistent access, without the user realizing something is wrong.

Using a strict CSP policy, combined with other security best-practices such as adopting template systems with strict contextual auto-escaping, vulnerability scanning, and a manual security review, can significantly decrease the risk that an XSS bug will be introduced and that it can be exploited against users of modern browsers. Especially in cases where otherwise well-designed applications suffer from subtle, difficult to spot XSS issues, CSP can provide an important second layer of defense and protect the application's users.

Note: Traditional CSP policies based on URL whitelists are generally ineffective at preventing attackers from exploiting XSS, as discussed in this research paper. Instead, we use an alternative approach based on cryptographic nonces.

When to use CSP

As a general rule, a majority of complex web applications are susceptible to XSS, and would benefit from adopting CSP.

In particular, CSP is recommended for applications which manage sensitive data such as administrative UIs and device management consoles, or products hosting user-generated documents, messages or media files. Especially in products using modern frameworks (Closure Templates) adopting CSP can be relatively straightforward and provide a large security improvement in exchange for a small time investment.

When not to use CSP

There are several types of applications where adding CSP might not be the best choice, and focusing on other security improvements would have more impact:

• Static applications without any logged-in functionality or cookies, which are hosted in their own (sub)domains. In such cases XSS is a minor concern.

• Large applications with a history of XSS, which use template systems and frameworks without sufficient protections against XSS. CSP is an additional security mechanism, not a substitute for a well-designed, secure codebase. In such instances, spending time to improve the security posture of the application (adopting safer frameworks, reviewing critical parts of the code) is the best approach.

CSP is a flexible standard and it makes it possible to define policies which don't provide any useful security guarantees. Creating a policy which allows inline scripts (script-src 'unsafe-inline') or allows loading scripts from untrusted domains does not improve security because it doesn't protect the application from XSS. If an application cannot use a safe policy it will not benefit from CSP until all patterns incompatible with CSP are removed; as such, it is prudent to hold off on deploying a policy until the application can adopt strict CSP.