CINXE.COM
Introduction - Content Security Policy
<!doctype html> <html class="google" lang="en"> <head> <meta charset="utf-8"> <title>Introduction - Content Security Policy</title> <link href="https://fonts.googleapis.com/css?family=Open+Sans:300,400,600,700&lang=en" rel="stylesheet"> <link href="https://www.google.com/css/maia.css" rel="stylesheet"> <link href="https://fonts.googleapis.com/icon?family=Material+Icons" rel="stylesheet"> <link href="style.css" rel="stylesheet"> </head> <body> <div class="maia-header" id="maia-header" role="banner"> <div class="maia-aux"> <div id="product"> <a href="/"> <span class="cspdoc-site-title">Content Security Policy</span> </a> </div> <div class="clear"></div> </div> <div class="maia-nav" id="maia-nav-x" role="navigation"> <div class="maia-aux cspdoc-navbar-content"> <ul> <li><b>Introduction</b></li> <li><a href="why-csp.html">Why CSP</a></li> <li><a href="strict-csp.html">Strict CSP</a></li> <li><a href="adopting-csp.html">Adopting CSP</a></li> <li><a href="faq.html">FAQ</a></li> <li><a href="resources.html">Resources</a></li> </ul> </div> </div> <div class="maia-breadcrumb"></div> </div> <div id="maia-main" role="main"> <div class="maia-cols"> <div class="maia-col-9" id="content"> <div id="deprecation-warning"> This documentation is outdated and available for historical reasons only. To learn how to enable strict Content Security Policy in your application, visit <a href="https://web.dev/strict-csp">web.dev/strict-csp</a>. </div> <div class="cspdoc-content" id="article"> <h1>Introduction</h1> <p>Content Security Policy is a mechanism designed to make applications more secure against common web vulnerabilities, particularly <a href="https://www.google.com/about/appsecurity/learning/xss/">cross-site scripting</a>. It is enabled by setting the <code>Content-Security-Policy</code> HTTP response header.</p> <p>The core functionality of CSP can be divided into three areas:</p> <ul> <li> <p>Requiring that all scripts are safe and trusted by the application owner (ideally by making sure they match an unpredictable identifier specified in the policy called the <em>CSP nonce</em>),</p> </li> <li> <p>Ensuring that page resources, such as images, stylesheets, or frames, are loaded from trusted sources,</p> </li> <li> <p>Miscellaneous other security features: preventing the application from being framed by untrusted domains, transparently upgrading all resource requests to HTTPS, and others.</p> </li> </ul> <p>By adopting a <a href="strict-csp.html">strict policy</a>, 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 <a href="why-csp.html">the most common and dangerous</a> web vulnerabilities.</p> <p>An application can define a policy by setting the following header:</p> <pre class=code> Content-Security-Policy: default-src https:; script-src 'nonce-{random}'; object-src 'none' </pre> <p>This policy will require all resources to be loaded over HTTPS, allow only <code><script></code> elements with the correct <code>nonce</code> attribute, and prevent loading any plugins.</p> <p><strong>Note</strong>: Real policies are a bit more complicated for compatibility and security reasons; see <a href="strict-csp.html#example">this example</a>.</p> <p>CSP support is available in several popular template systems and frameworks (for example, <a href="https://developers.google.com/closure/templates/">Closure Templates</a> can <a href="https://developers.google.com/closure/templates/docs/security#content_security_policy">automatically add CSP nonces</a>). Several <a href="resources.html#tools">helper tools</a> can assist you in building a secure policy, identifying any necessary markup changes, and monitoring the effects of the policy after deployment.</p> <!-- Due to implementation issues across browsers, we suggest to send a CSP header only for Chrome/Chromium >= 53 (due to issues with nonces and HTTP redirects), Firefox >= 43 ([bug](https://bugzilla.mozilla.org/show_bug.cgi?id=1026520)) and Opera >= 40. If you are a CSP wizard and you are planning on sending out more than one header, send them only for Chrome/Chromium >= 55, Firefox >= 43 and Opera >= 42. --> <h1>What should I do now?</h1> <p>Adopting a safe CSP policy can be an important security improvement 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:</p> <ul> <li> <p><a href="why-csp.html">Why CSP</a> is a short explainer document discussing the benefits of using CSP, and examining when a policy is most useful for an application.</p> </li> <li> <p><a href="strict-csp.html">Strict CSP</a> describes the proposed approach for using CSP to defend against XSS. <a href="adopting-csp.html">Adopting CSP</a> 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.</p> </li> <li> <p>The <a href="faq.html">FAQ</a> discusses common adoption and security issues, including a <a href="faq.html#comparison">comparison</a> of the <em>strict CSP</em> approach to traditional policies.</p> </li> <li> <p>The <a href="resources.html">Resources page</a> contains links to useful tools, code examples, and additional documentation.</p> </li> </ul> </div> <div></div> </div> <div class="maia-col-3 sidebar"> <h2>Site Contents</h2> <div class="maia-aside cspdoc-sitemap-content"> <ul> <li><a href="index.html">Introduction</a></li> <li><a href="why-csp.html">Why CSP</a></li> <li><a href="strict-csp.html">Strict CSP</a></li> <li><a href="adopting-csp.html">Adopting CSP</a></li> <li><a href="faq.html">FAQ</a></li> <li><a href="resources.html">Resources</a></li> </ul> </div> </body> </html>