CSP source values

HTTP Content-Security-Policy (CSP) fetch directives may take as a value a space-separated list of source expressions. Each source expression can be any of the values listed below.

As well as fetch directives, some other CSP directives may take as a value a space-separated list of source expressions, each of which may be a subset of the values listed below, namely: one of <host-source>, <scheme-source>, or the keyword 'self'. These other directives are:

Directives that accept a list of source expressions may instead be given the single value 'none', indicating that no resources of the given type may be loaded (or, in the case of non-fetch directives, that the associated feature is not allowed).

Sources

<host-source>

Internet host by name or IP address. The URL scheme, port number, and path are optional. Wildcards ('*') can be used for subdomains, host address, and port number, indicating that all legal values of each are valid. When matching schemes, secure upgrades are allowed (e.g. specifying http://example.com will match https://example.com). Examples:

  • http://*.example.com: Matches all attempts to load from any subdomain of example.com. Also matches https resources.
  • mail.example.com:443: Matches all attempts to load from port 443 on mail.example.com.
  • https://store.example.com: Matches all attempts to access store.example.com using https:.
  • *.example.com: Matches all attempts to load from any subdomain of example.com.
  • https://*.example.com:12/path/to/file.js: Matches all attempts to load from any subdomain of example.com using https: on port 12, and only if the path is /path/to/file.js.
  • ws://example.com: Matches all attempts to load from example.com using ws:. Also matches wss resources.
  • https://example.com/subdirectory: Matches all attempts to load the exact path https://example.com/subdirectory.
  • https://example.com/subdirectory/: Matches all attempts to load files under subdirectory directory. For example, https://example.com/subdirectory/path/to/file.js. It does not match https://example.com/path/to/file.js.

For more details about how path matching is done refer the parts matching algorithms in the specification.

<scheme-source>

A scheme such as http: or https:. The colon is required. Unlike other values below, single quotes shouldn't be used. You can also specify data schemes (not recommended).

  • data: Allows data: URLs to be used as a content source. This is insecure; an attacker can also inject arbitrary data: URLs. Use this sparingly and definitely not for scripts.
  • mediastream: Allows mediastream: URIs to be used as a content source.
  • blob: Allows blob: URIs to be used as a content source.
  • filesystem: Allows filesystem: URIs to be used as a content source.

Note: If a scheme source is missing, the document origin's scheme is used. Secure upgrades are allowed, so if the document is loaded using https:, then example.com will match https://example.com but not http://example.com. For more information, see CSP Level 3.

'self'

Refers to the origin from which the protected document is being served, including the same URL scheme and port number. You must include the single quotes. Some browsers specifically exclude blob and filesystem from source directives. Sites needing to allow these content types can specify them using the Data attribute.

'unsafe-eval'

Allows the use of eval() and other unsafe methods for creating code from strings. You must include the single quotes.

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

'unsafe-hashes'

Allows enabling specific inline event handlers. If you only need to allow inline event handlers and not inline <script> elements or javascript: URLs, this is a safer method than using the unsafe-inline expression.

'unsafe-inline'

Allows the use of inline resources, such as inline <script> elements, javascript: URLs, inline event handlers, and inline <style> elements. The single quotes are required.

'nonce-<base64-value>'

An allowlist for specific scripts using a cryptographic nonce (number used once). The server must generate a unique nonce value each time it transmits a policy. It is critical to provide an unguessable nonce, as bypassing a resource's policy is otherwise trivial. See unsafe inline script for an example. Specifying nonce makes a modern browser ignore 'unsafe-inline' which could still be set for older browsers without nonce support.

Note: The CSP nonce source can only be applied to nonceable elements (e.g., as the <img> element has no nonce attribute, there is no way to associate it with this CSP source).

'<hash-algorithm>-<base64-value>'

A sha256, sha384 or sha512 hash of scripts or styles. This value consists of the algorithm used to create the hash followed by a hyphen and the base64-encoded hash of the script or style. When generating the hash, exclude <script> or <style> tags and note that capitalization and whitespace matter, including leading or trailing whitespace. In CSP 2.0, hash sources can be applied to inline scripts and styles. Hash source expressions are allowed in CSP 3.0 for external scripts in script-src directives. See the script-src and style-src pages for more information and examples.

'strict-dynamic'

The strict-dynamic source expression specifies that the trust explicitly given to a script present in the markup, by accompanying it with a nonce or a hash, shall be propagated to all the scripts loaded by that root script. At the same time, any allowlist or source expressions such as 'self' or 'unsafe-inline' are ignored. See script-src for an example.

'report-sample'

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

Specifications

Specification
Content Security Policy Level 3
# framework-directive-source-list