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
For more information, see the introductory article on Content Security Policy (CSP).
|Header type||Response header|
|Forbidden header name||no|
Content-Security-Policy: <policy-directive>; <policy-directive>
<policy-directive> consists of:
<directive> <value> with no internal punctuation.
Fetch directives control the locations from which certain resource types may be loaded.
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 of images and favicons.
Specifies valid sources of application manifest files.
Note: Elements controlled by
object-srcare perhaps coincidentally considered legacy HTML elements and are not receiving new standardized features (such as the security attributes
<iframe>). Therefore it is recommended to restrict this fetch-directive (e.g., explicitly set
object-src 'none'if possible).
Specifies valid sources to be prefetched or prerendered.
Specifies valid sources for stylesheets.
Specifies valid sources for inline styles applied to individual DOM elements.
Document directives govern the properties of a document or worker environment to which a policy applies.
Navigation directives govern to which locations a user can navigate or submit a form, for example.
Restricts the URLs which can be used as the target of a form submissions from a given context.
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.
Warning: Though the
report-todirective is intended to replace the deprecated
report-tois not 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.example.com; report-to groupname > ```
In browsers that support
report-uridirective will be ignored.
Requires the use of SRI for scripts or styles on the page.
Enforces Trusted Types at the DOM XSS injection sinks.
Used to specify an allow-list of Trusted Types policies. Trusted Types allows applications to lock down DOM XSS injection sinks to only accept non-spoofable, typed values in place of strings.
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.
Prevents loading any assets using HTTP when the page is loaded using HTTPS.
Restricts the set of plugins that can be embedded into a document by limiting the types of resources which can be loaded.
Won't allow loading of any resources.
Only allow resources from the current origin.
Only allow loading of resources from a specific host, with optional scheme, port, and path. e.g.
Only allow loading of resources over a specific scheme, should always end with "
A cryptographic nonce (only used once) to allow scripts. The server must generate a unique nonce value each time it transmits a policy. It is critical to provide a nonce that cannot be guessed as bypassing a resource's policy is otherwise trivial. This is used in conjunction with the script tag nonce attribute. e.g.
sha256, sha384, or sha512. followed by a dash and then the sha* value. e.g.
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.
You can use the
Content-Security-Policy header more than once, as 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,
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:
Content-Security-Policy: default-src https:
<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 to disable plugins:
Content-Security-Policy: default-src https: 'unsafe-eval' 'unsafe-inline'; object-src 'none'
Example: Do not 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 (Content Security Policy 3)|
BCD tables only load in the browser