The HTTP 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 (Cross-site_scripting).
Defines the valid sources for web workers and nested browsing contexts loaded using elements such as <frame> and <iframe>.
Warning: Instead of child-src, if you want to regulate nested browsing contexts and workers, you should use the frame-src and worker-src directives, respectively.
Note: Elements controlled by object-src are perhaps coincidentally considered legacy HTML elements and are not receiving new standardized features (such as the security attributes sandbox or allow for <iframe>). Therefore it is recommended to restrict this fetch-directive (e.g., explicitly set object-src 'none' if possible).
Instructs the user agent to report attempts to violate the Content Security Policy. These violation reports consist of JSON documents sent via an HTTP POST request to the specified URI.
Warning: Though the report-to directive is intended to replace the deprecated report-uri directive, report-to is not supported in most browsers yet. So for compatibility with current browsers while also adding forward compatibility when browsers get report-to support, you can specify both report-uri and report-to:
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 websites with large numbers of insecure legacy URLs that need to be rewritten.
Used to specify information in the Referer (sic) header for links away from a page. Use the Referrer-Policy header instead.
Values
An overview of the allowed values are listed below. For detailed reference see CSP Source Values and the documentation for individual directives.
Keyword values
none
Won't allow loading of any resources.
self
Only allow resources from the current origin.
strict-dynamic
The trust granted to a script in the page due to an accompanying nonce or hash is extended to the scripts it loads.
report-sample
Require a sample of the violating code to be included in the violation report.
Unsafe keyword values
unsafe-inline
Allow use of inline resources.
unsafe-eval
Allow use of dynamic code evaluation such as eval, setImmediateNon-standard , and window.execScriptNon-standard .
unsafe-hashes
Allows enabling specific inline event handlers.
unsafe-allow-redirectsExperimental
TBD
Hosts values
Host
Only allow loading of resources from a specific host, with optional scheme, port, and path. e.g. example.com, *.example.com, https://*.example.com:12/path/to/file.js
Path parts in the CSP that end in / match any path they are a prefix of. e.g. example.com/api/ will match URLs like example.com/api/users/new.
Other path parts in the CSP are matched exactly e.g. example.com/file.js will match http://example.com/file.js and https://example.com/file.js, but not https://example.com/file.js/file2.js
Scheme
Only allow loading of resources over a specific scheme, should always end with ":". e.g. https:, http:, data: etc.
Other values
nonce-*
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. nonce-DhcnhD3khTMePgXwdayK9BsMqXjhguVV
sha*-*
sha256, sha384, or sha512. followed by a dash and then the sha* value. e.g. sha256-jzgBGA4UWFFmpOBq0JpdsySukE1FrEN5bUpoK8Z29fY=
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
The CSP mechanism allows multiple policies being specified for a resource, including via the Content-Security-Policy header, the Content-Security-Policy-Report-Only header and a <meta> element.
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, connect-src 'none' is enforced.