Content-Security-Policy

Baseline Widely available

This feature is well established and works across many devices and browser versions. It’s been available across browsers since August 2016.

The HTTP Content-Security-Policy response header allows website 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).

For more information, see the introductory article on Content Security Policy (CSP).

Header type Response header
Forbidden header name no

Syntax

http
Content-Security-Policy: <policy-directive>; <policy-directive>

where <policy-directive> consists of: <directive> <value> with no internal punctuation.

Directives

Fetch directives

Fetch directives control the locations from which certain resource types may be loaded.

child-src

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.

connect-src

Restricts the URLs which can be loaded using script interfaces.

default-src

Serves as a fallback for the other fetch directives.

fenced-frame-src Experimental

Specifies valid sources for nested browsing contexts loaded into <fencedframe> elements.

font-src

Specifies valid sources for fonts loaded using @font-face.

frame-src

Specifies valid sources for nested browsing contexts loaded into elements such as <frame> and <iframe>.

img-src

Specifies valid sources of images and favicons.

manifest-src

Specifies valid sources of application manifest files.

media-src

Specifies valid sources for loading media using the <audio>, <video> and <track> elements.

object-src

Specifies valid sources for the <object> and <embed> elements.

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).

prefetch-src Deprecated Non-standard

Specifies valid sources to be prefetched or prerendered.

script-src

Specifies valid sources for JavaScript and WebAssembly resources.

script-src-elem

Specifies valid sources for JavaScript <script> elements.

script-src-attr

Specifies valid sources for JavaScript inline event handlers.

style-src

Specifies valid sources for stylesheets.

style-src-elem

Specifies valid sources for stylesheets <style> elements and <link> elements with rel="stylesheet".

style-src-attr

Specifies valid sources for inline styles applied to individual DOM elements.

worker-src

Specifies valid sources for Worker, SharedWorker, or ServiceWorker scripts.

Document directives

Document directives govern the properties of a document or worker environment to which a policy applies.

base-uri

Restricts the URLs which can be used in a document's <base> element.

sandbox

Enables a sandbox for the requested resource similar to the <iframe> sandbox attribute.

Navigation directives govern to which locations a user can navigate or submit a form, for example.

form-action

Restricts the URLs which can be used as the target of a form submissions from a given context.

frame-ancestors

Specifies valid parents that may embed a page using <frame>, <iframe>, <object>, or <embed>.

Reporting directives

Reporting directives control the destination URL for CSP violation reports in Content-Security-Policy and Content-Security-Policy-Report-Only.

report-to

Provides the browser with a token identifying the reporting endpoint or group of endpoints to send CSP violation information to. The endpoints that the token represents are provided through other HTTP headers, such as Reporting-Endpoints and Report-To Deprecated .

Warning: This directive is intended to replace report-uri; in browsers that support report-to, the report-uri directive is ignored. However until report-to is broadly supported you should specify both headers as shown (where endpoint_name is the name of a separately provided endpoint):

http
Content-Security-Policy: …; report-uri https://endpoint.example.com; report-to endpoint_name

Other directives

require-trusted-types-for Experimental

Enforces Trusted Types at the DOM XSS injection sinks.

trusted-types Experimental

Used to specify an allowlist 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.

upgrade-insecure-requests

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.

Deprecated directives

block-all-mixed-content Deprecated

Prevents loading any assets using HTTP when the page is loaded using HTTPS.

report-uri Deprecated

Provides the browser with a URL where CSP violation reports should be sent. This has been superseded by the report-to directive.

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.

'inline-speculation-rules'

Allows the inclusion of speculation rules in scripts (see also <script type="speculationrules">).

Unsafe keyword values

'unsafe-inline'

Allow use of inline resources.

'unsafe-eval'

Allow use of dynamic code evaluation such as eval, setTimeout(), and window.execScript Non-standard .

'unsafe-hashes'

Allows enabling specific inline event handlers.

'wasm-unsafe-eval'

Allows the loading and execution of WebAssembly modules without the need to also allow unsafe JavaScript execution via 'unsafe-eval'. The single quotes are required.

Hosts values

  • Host

    • Only allow loading of resources from a specific host, with optional scheme, port, and path. For example, 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. For example, example.com/api/ will match URLs like example.com/api/users/new.
    • Other path parts in the CSP are matched exactly; for example, 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 :. For example, 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. For example, nonce-DhcnhD3khTMePgXwdayK9BsMqXjhguVV.

'sha*-*'

sha256, sha384, or sha512. Followed by a dash and then the sha* value. For example, 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.

http
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/

Examples

Disable unsafe inline code and only allow HTTPS resources

This HTTP header sets the default policy to only allow resource loading (images, fonts, scripts, etc.) over HTTPS. Because the unsafe-inline and unsafe-eval directives are not set, inline scripts will be blocked.

http
Content-Security-Policy: default-src https:

The same restrictions can be applied using the HTML <meta> element.

html
<meta http-equiv="Content-Security-Policy" content="default-src https:" />

Allow inline code and HTTPS resources, but disable plugins

This policy could be used on a pre-existing site that uses too much inline code to fix, to ensure resources are loaded only over HTTPS and disable plugins:

http
Content-Security-Policy: default-src https: 'unsafe-eval' 'unsafe-inline'; object-src 'none'

Report but don't enforce violations when testing

This example sets the same restrictions as the previous example, but using the Content-Security-Policy-Report-Only header and the report-to directive. This approach is used during testing to report violations but not block code from executing.

Endpoints (URLs) to send reports to are defined using the Reporting-Endpoints HTTP response header.

http
Reporting-Endpoints: csp-endpoint="https://example.com/csp-reports"

A particular endpoint is then selected as the report target in the CSP policy using the report-to directive.

http
Content-Security-Policy-Report-Only: default-src https:; report-uri /csp-violation-report-url/; report-to csp-endpoint

Note that the report-uri Deprecated directive is also specified above because report-to is not yet broadly supported by browsers.

See Content Security Policy (CSP) implementation for more examples.

Specifications

Specification
Content Security Policy Level 3
# csp-header

Browser compatibility

BCD tables only load in the browser

See also