Content-Security-Policy response header allows web site administrators to control resources the user agent is allowed to load for a given page. With a few exceptions, policies mostly involve specifying server origins and script endpoints. This helps guard against cross-site scripting attacks (XSS).
For more information, see also this article on Content Security Policy (CSP).
|Header type||Response header|
|Forbidden header name||no|
Content-Security-Policy: <policy-directive>; <policy-directive>
Fetch directives control locations from which certain resource types may be loaded.
- Defines the valid sources for web workers and nested browsing contexts loaded using elements such as
- Restricts the URLs which can be loaded using script interfaces
- Serves as a fallback for the other fetch directives.
- Specifies valid sources for fonts loaded using
- Specifies valid sources for nested browsing contexts loading using elements such as
- Specifies valid sources of images and favicons.
- Specifies valid sources of application manifest files.
- Specifies valid sources for loading media using the
- Specifies valid sources for the
Specifies valid sources to be prefetched or prerendered.
- Specifies valid sources for stylesheets.
- Specifies valid sources for
Document directives govern the properties of a document or worker environment to which a policy applies.
- Restricts the URLs which can be used in a document's
- Restricts the set of plugins that can be embedded into a document by limiting the types of resources which can be loaded.
- Enables a sandbox for the requested resource similar to the
- Ensures a resource will disown its opener when navigated to.
Navigation directives govern to which location a user can navigate to or submit a form to, for example.
- Restricts the URLs which can be used as the target of a form submissions from a given context.
- Specifies valid parents that may embed a page using
- Restricts the URLs to which a document can navigate by any means (a, form, window.location, window.open, etc.)
Reporting directives control the reporting process of CSP violations. See also the
- Instructs the user agent to report attempts to violate the Content Security Policy. These violation reports consist of JSON documents sent via an HTTP
POSTrequest to the specified URI.
report-todirective is intended to replace the deprecated
report-toisn’t supported in most browsers yet. So for compatibility with current browsers while also adding forward compatibility when browsers get
report-tosupport, you can specify both
Content-Security-Policy: ...; report-uri https://endpoint.com; report-to groupname
In browsers that support
report-uridirective will be ignored.
- Fires a
- Prevents loading any assets using HTTP when the page is loaded using HTTPS.
- Used to specify information in the referer (sic) header for links away from a page. Use the
- Requires the use of SRI for scripts or styles on the page.
- Instructs user agents to treat all of a site's insecure URLs (those served over HTTP) as though they have been replaced with secure URLs (those served over HTTPS). This directive is intended for web sites with large numbers of insecure legacy URLs that need to be rewritten.
CSP in workers
Workers are in general not governed by the content security policy of the document (or parent worker) that created them. To specify a content security policy for the worker, set a
Content-Security-Policy response header for the request which requested the worker script itself.
The exception to this is if the worker script's origin is a globally unique identifier (for example, if its URL has a scheme of data or blob). In this case, the worker does inherit the content security policy of the document or worker that created it.
Multiple content security policies
You can use the
Content-Security-Policy header more than once like in the example below. Pay special attention to the
connect-src directive here. Even though the second policy would allow the connection, the first policy contains
connect-src 'none'. Adding additional policies can only further restrict the capabilities of the protected resource, which means that there will be no connection allowed and, as the strictest policy,
connect-src 'none' is enforced.
Content-Security-Policy: default-src 'self' http://example.com; connect-src 'none'; Content-Security-Policy: connect-src http://example.com/; script-src http://example.com/
Example: Disable unsafe inline/eval, only allow loading of resources (images, fonts, scripts, etc.) over https:
// header Content-Security-Policy: default-src https: // meta tag <meta http-equiv="Content-Security-Policy" content="default-src https:">
Example: Pre-existing site that uses too much inline code to fix but wants to ensure resources are loaded only over https and disable plugins:
Content-Security-Policy: default-src https: 'unsafe-eval' 'unsafe-inline'; object-src 'none'
Example: Don't implement the above policy yet; instead just report violations that would have occurred:
Content-Security-Policy-Report-Only: default-src https:; report-uri /csp-violation-report-endpoint/
See Mozilla Web Security Guidelines for more examples.
|Content Security Policy Level 3||Working Draft||Adds
|Mixed Content||Candidate Recommendation||Adds
|Upgrade Insecure Requests||Candidate Recommendation||Adds
|Content Security Policy Level 2||Recommendation||Adds
|Content Security Policy 1.0||Obsolete||Defines
The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out https://github.com/mdn/browser-compat-data and send us a pull request.
|Feature||Android webview||Chrome for Android||Edge mobile||Firefox for Android||Opera Android||iOS Safari||Samsung Internet|
1. Implemented as X-Webkit-CSP header in Chrome 14.
2. Implemented as X-Content-Security-Policy header in Firefox 4.
3. Implemented as X-Content-Security-Policy header, only supporting 'sandbox' directive.
4. Implemented as X-Webkit-CSP header in Safari 6.
5. Implemented as X-Webkit-CSP header in iOS 5.1.