Content Security Policy is a mechanism designed to make applications more secure against common web vulnerabilities, particularly cross-site scripting. It is enabled by delivering a policy string in the Content-Security-Policy HTTP response header.

The core functionality of CSP can be divided into three areas:

  • Requiring that all loaded scripts are safe and trusted by the application owner (ideally, by making sure they match an unpredictable identifier specified in the policy called the CSP nonce),

  • Ensuring that page resources, such as images, stylesheets, or frames, are loaded from trusted sources,

  • Miscellaneous other security features: preventing the application from being framed by untrusted domains, transparently upgrading all resource requests to HTTPS, and others.

By adopting a strict policy, which prevents the loading of untrusted scripts or plugins, an application can add an important defense-in-depth layer against markup injection attacks. This documentation focuses on the XSS mitigation aspect of CSP, because XSS is one of the most common and dangerous web vulnerabilities.

An application can define a policy by setting the following header:

Content-Security-Policy: default-src https:; script-src 'nonce-{random}'; object-src 'none'

This policy will require all resources to be loaded over HTTPS, will allow only <script> elements with a correct nonce attribute, and will prevent loading any plugins such as Flash. Note: Real policies are a bit more complicated for backwards-compatibility reasons; see this example.

CSP support is available in several popular template systems and frameworks (for example, Closure Templates can automatically add CSP nonces to all <script> elements). Several helper tools can assist you in building a secure policy, identifying any necessary markup changes, and monitoring the effects of the policy after deployment.

What should I do now?

Adopting a safe CSP policy can be one of the most high-impact security improvements for many applications. To see if it's right for your app, and learn what you need to do to enable CSP, take a look at the following pages:

  • Why CSP is a short explainer document discussing the benefits of using CSP, and examining when a policy is most useful for an application.

  • Strict CSP describes the proposed approach for using CSP to defend against XSS. Adopting CSP shows the recommended way to make an application compatible with CSP, including a production-ready policy, example code, and overview of tools which help you deploy a secure policy.

  • The FAQ discusses common adoption and security issues, including a comparison of the strict CSP approach to traditional policies.

  • The Resources page contains links to useful tools, code examples, and additional documentation.