CSP Policy Directives

There are several policy areas that web site administrators can define using Content Security Policy (CSP). Any combination of these can be used to suit your web site's needs; you don't need to specify them all.

Content sources

Most policy directives require one or more content sources. A content source is a string indicating a possible source from which content might be loaded.

Source lists

A source list is a string specifying one or more Internet hosts by name or IP address, as well as an optional URL scheme and/or port number. The site's address may include an optional leading wildcard (the asterisk character, '*'), and you may use a wildcard (again, '*') as the port number, indicating that all legal ports are valid for the source. The hosts are space-delimited.

Valid host expressions include:

https://*.example.com

Matches all attempts to load from any subdomain of example.com using the http: URL scheme.

mail.example .com:443

Matches all attempts to access port 443 on mail.example.com.

https://store.example.com

Matches all attempts to access store.example.com using https:.

If a port number isn't specified, the browser will use the default port number for the specified scheme. If no scheme is specified, the same scheme as the one used to access the protected document is assumed.

Keywords

There are also some keywords available to describe special classes of content sources. These are:

'none'

Refers to the empty set; that is, no URLs match. The single quotes are required.

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

Allows the use of inline resources, such as inline <script> elements, javascript: URLs, inline event handlers, and inline <style> elements. You must include the single quotes.

'unsafe-eval'

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

For example, you can specify that content may be loaded from the document's origin as well as trustedscripts.example.com as follows:

Content-Security-Policy: default-src 'self' trustedscripts.example.com

Data

data:

Allows data: URIs to be used as a content source. This is insecure; an attacker can also inject arbitrary data: URIs. 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.

Content-Security-Policy: default-src 'self'; img-src 'self' data: blob: filesystem:; media-src mediastream:

Supported policy directives

The following policy directives are available to control the security policy for the various policy areas.

base-uri

The base-uri directive defines the URIs that a user agent may use as the document base URL. If this value is absent, then any URI is allowed. If this directive is absent, the user agent will use the value in the base element.

base-uri source-list

child-src

The child-src directive defines the valid sources for web workers and nested browsing contexts loaded using elements such as <frame> and <iframe>. This directive is preferred over the frame-src directive, which is deprecated. For workers, non-compliant requests are treated as fatal network errors by the user agent.

​child-src source-list

connect-src

The connect-src directive defines valid sources for Fetch, XMLHttpRequest, WebSocket, and EventSource connections.

connect-src source-list

default-src

The default-src directive defines the security policy for types of content which are not expressly called out by more specific directives. This directive covers the following directives:

• child-src
• connect-src
• font-src
• img-src
• manifest-src
• media-src
• object-src
• script-src
• style-src

default-src source-list

font-src

The font-src directive specifies valid sources for fonts loaded using @font-face.

font-src source-list

form-action

The form-action directive specifies valid endpoints for <form> submissions.

form-action source-list

frame-ancestors

The frame-ancestors directive specifies valid parents that may embed a page using the <frame> and <iframe> elements. This directive is not supported in the <meta> element or by the Content-Security-Policy-Report-Only header field.

frame-ancestors source-list

frame-src

The frame-src directive specifies valid sources for web workers and nested browsing contexts loading using elements such as <frame> and <iframe>.

frame-src source-list

img-src

The img-src directive specifies valid sources of images and favicons.

img-src source-list

manifest-src

The manifest-src directive specifies which manifest can be applied to the resource.

manifest-src source-list

media-src

The media-src directive specifies valid sources for loading media using the <audio> and <video> elements.

media-src source-list

object-src

The object-src directive specifies valid sources for the <object>, <embed>, and <applet> elements.

object-src source-list

plugin-types

The plugin-types directive specifies the valid plugins that the user agent may invoke.

plugin-types type-list

referrer

The referrer directive specifies information in the referer (sic) header for links away from a page. Valid values are no-referrer, no-referrer-when-downgrade, origin, origin-when-cross-origin, and unsafe-url.

​referrer value

reflected-xss

The reflected-xss directive instructs a user agent to activate or deactivate any heuristics used to filter or block reflected cross-site scripting attacks. Valid values are allow, block, and filter. This directive is not supported in the <meta> element.

reflected-xss value

report-uri

The report-uri directive 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. See Using CSP violation reports for details. This directive is not supported in the <meta> element.

report-uri uri

sandbox

The sandbox directive applies restrictions to a page's actions including preventing popups, preventing the execution of plugins and scripts, and enforcing a same-origin policy. This directive is not supported in the <meta> element or by the Content-Security-policy-Report-Only header field.

sandbox value

script-src

The script-src directive specifies valid sources for JavaScript. When either the script-src or the default-src directive is included, inline script and eval() are disabled unless you specify 'unsafe-inline' and 'unsafe-eval', respectively. In Chrome 49 and later, 'script-src http' will match both HTTP and HTTPS.

script-src source-list

strict-dynamic

The strict-dynamic directive 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 whitelist or source expressions such as 'self' or 'unsafe-inline' will be ignored. For example, a policy such as script-src 'strict-dynamic' 'nonce-R4nd0m' https://whitelisted.com/ would allow loading of a root script with <script nonce="R4nd0m" src="https://example.com/loader.js">  and propogate that trust to any script loaded by loader.js, but disallow loading scripts from https://whitelisted.com/.

script-src 'strict-dynamic' 'nonce-someNonce'

Or

script-src 'strict-dynamic' 'sha256-hash'

It is possible to deploy strict-dynamic in a backwards compatible way, without requiring user-agent sniffing.
The policy:

script-src 'unsafe-inline' https: 'nonce-abcdefg' 'strict-dynamic'

will act like'unsafe-inline' https: in browsers that support CSP1, https: 'nonce-abcdefg' in browsers that support CSP2, and 'nonce-abcdefg' 'strict-dynamic' in browsers that support CSP3.

style-src

The style-src directive specifies valid sources for stylesheets. This includes both externally-loaded stylesheets and inline use of the <style> element and HTML style attributes. Stylesheets from sources that aren't included in the source list are not requested or loaded. When either the style-src or the default-src directive is included, inline use of the <style> element and HTML style attributes are disabled unless you specify 'unsafe-inline'.

style-src source-list

upgrade-insecure-requests

The upgrade-insecure-requests directive instructs user agents to treat all of a site's unsecure URL's (those served over HTTP) as though they have been replaced with secure URL's (those served over HTTPS). This directive is intended for web sites with large numbers of unsecure legacy URL's that need to be rewritten.

Specifications

Browser compatibility

[1] Deprecated since Android 4.0.

[2] Starting with version 45.0, Chrome excludes blob and filesystem from source directives. Sites needing to allow these content types can specify them using the Data attribute.

[3] Starting with Chrome 45, the referrer policy is constrained to the values defined in the Referrer Policy specification.

[4] Implemented as X-Webkit-CSP header.

[5] Implemented as X-Content-Security-Policy header.

[6] Prior to Firefox 50, the ping attribute of <a> element wasn't abiding by it.

See also

• Introducing Content Security Policy
• Using Content Security Policy
• Using CSP violation reports