Content Security Policy Level 2

Resource Type	What policy applies?
Top-level Contexts	HTML as a new, top-level browsing context	The policy delivered with the resource applies.
SVG, as a top-level document	The policy delivered with the resource applies.
Embedded Contexts	Any resource included via <{iframe}>, <{object}>, or <{embed}>	Unless the embedded resource is a globally unique identifier (or a srcdoc iframe), the embedded resource is controlled by the policy delivered with the resource. If the embedded resource is a globally unique identifier or srcdoc iframe, it inherits the policy of the context creating it. (The frame-src and child-src directives of the embedding context only control what resources are eligible for embedding in that context, not the behavior of the resource once embedded.)
SVG, as an embedded document	Unless the resource is a globally unique identifier, it is controlled by the policy delivered with the resource. If a globally unique identifier, it inherits the policy of the context creating it.
JavaScript, as a Worker, Shared Worker, or Service Worker	Unless the resource is a globally unique identifier, it is controlled by the policy delivered with the resource. If a globally unique identifier, it inherits the policy of the context creating it.
Subresources	SVG, inlined via <{svg}>	The policy of the including context applies.
SVG, as a resource document	The policy of the including context applies.
HTML via XMLHttpRequest	The policy of the context that performed the fetch applies.
Image via <{img}> element	The policy of the including context applies.
JavaScript via a <{script}> element	The policy of the including context applies.
SVG, via <{img}>	No policy applies; this should be just as safe as JPG
SVG, as a WebFont	No policy applies; this should be just as safe as WOFF

1. Introduction

This section is not normative.

This document defines Content Security Policy, a mechanism web applications can use to mitigate a broad class of content injection vulnerabilities, such as cross-site scripting (XSS). Content Security Policy is a declarative policy that lets the authors (or server administrators) of a web application inform the client about the sources from which the application expects to load resources.

To mitigate XSS attacks, for example, a web application can declare that it only expects to load script from specific, trusted sources. This declaration allows the client to detect and block malicious scripts injected into the application by an attacker.

Content Security Policy (CSP) is not intended as a first line of defense against content injection vulnerabilities. Instead, CSP is best used as defense-in-depth, to reduce the harm caused by content injection attacks. As a first line of defense against content injection, server operators should validate their input and encode their output.

There is often a non-trivial amount of work required to apply CSP to an existing web application. To reap the greatest benefit, authors will need to move all inline script and style out-of-line, for example into external scripts, because the user agent cannot determine whether an inline script was injected by an attacker.

To take advantage of CSP, a web application opts into using CSP by supplying a Content-Security-Policy HTTP header. Such policies apply to the current resource representation only. To supply a policy for an entire site, the server needs to supply a policy with each resource representation.

1.1. Changes from Level 1

This document describes an evolution of the Content Security Policy specification. Level 2 makes two breaking changes from Level 1, and adds support for a number of new directives and capabilities which are summarized below:

The following changes are backwards incompatible with the majority of user agent’s implementations of CSP 1:
1. The path component of a source expression is now ignored if the resource being loaded is the result of a redirect, as described in §4.2.2.3 Paths and Redirects.
  Note: Paths are technically new in CSP2, but they were already implemented in many user agents before this revision of CSP was completed, so noting the change here seems reasonable.
2. Redirects are blocked by default, and explicitly allowed with a new unsafe-redirect expression.
3. A protected resource’s ability to load Workers is now controlled via child-src rather than script-src.
4. Workers now have their own policy, separate from the protected resource which loaded them. This is described in §5.1 Workers.
The following directives are brand new in this revision:
1. base-uri controls the protected resource’s ability to specify the document base URL.
2. child-src deprecates and replaces frame-src, controlling the protected resource’s ability to embed frames, and to load Workers.
3. form-action controls the protected resource’s ability to submit forms.
4. frame-ancestors controls the protected resource’s ability be embedded in other documents. It is meant to supplant the X-Frame-Options HTTP request header.
5. plugin-types controls the protected resource’s ability to load specific types of plugins.
Individual inline scripts and stylesheets may be whitelisted via nonces (as described in §4.2.4 Valid Nonces) and hashes (as described in §4.2.5 Valid Hashes).
A CSP request header is now sent with relevant requests, as described in §3.4 The CSP HTTP Request Header.
A SecurityPolicyViolationEvent is fired upon violations, as described in §6.3 Firing Violation Events.
A number of new fields were added to violation reports (both those POSTED via report-uri, and those handed to the DOM via SecurityPolicyViolationEvent events. These include effectiveDirective, statusCode, sourceFile, lineNumber, and columnNumber.
Certain flags present in the sandbox directive now affect Worker creation, as described in §7.14.1 Sandboxing and Workers.

2. Key Concepts and Terminology

2.1. Terms defined by this specification

security policy

security policy directive

security policy directive name

security policy directive value

A security policy refers to both a set of security preferences for restrictions within which content can operate, and to a fragment of text that codifies or transmits these preferences. For example, the following string is a policy which restricts script and object content:

script-src 'self'; object-src 'none'

Security policies contain a set of security policy directives (script-src and object-src in the example above), each responsible for declaring the restrictions for a particular resource type, or manipulating a specific aspect of the policy’s restrictions. The list of directives defined by this specification can be found in §7 Directives.

Each directives has a name and a value; a detailed grammar can be found in §4 Syntax and Algorithms.

protected resource

A security policy is applied by a user agent to a specific resource representation, known as the protected resource. See §3 Policy Delivery for details regarding the mechanisms by which policies may be applied to a protected resource.

2.2. Terms defined by reference

globally unique identifier: Defined in Section 2.3 of the Origin specification. [RFC6454]
NOTE: URLs which do not use hierarchical elements as naming authorities (data:, for instance) have origins which are globally unique identifiers.
HTTP 200 response: Defined in Section 6.3.1 of HTTP/1.1 -- Semantics and Content. [RFC7231]
JSON object
JSON stringification: Defined in the JSON specification. [RFC4627]
origin: Defined by the Origin specification. [RFC6454]
resource representation: Defined in Section 3 of HTTP/1.1 -- Semantics and Content. [RFC7231]
URL: Defined by [URL].
SHA-256
SHA-384
SHA-512: These digest algorithms are defined by the NIST. [SHA2]

2.3. Relevant Concepts from HTML

The applet, audio, embed, iframe, img, link, object, script, source, track, and video are defined in [HTML5].

The terms auxiliary browsing contexts, opener browsing context, and nested browsing contexts are defined in the HTML5 specification. [HTML5]

A plugin is defined in the HTML5 specification. [HTML5]

The <@font-face> Cascading Style Sheets (CSS) rule is defined in the CSS Fonts Module Level 3 specification. [CSS3-FONTS]

The XMLHttpRequest object is defined in the XMLHttpRequest specification. [XMLHTTPREQUEST]

The WebSocket object is defined in the WebSocket specification. [WEBSOCKETS]

The EventSource object is defined in the EventSource specification. [EVENTSOURCE]

The runs a worker algorithm is defined in the Web Workers spec. [WORKERS]

The term callable refers to an object whose interface has one or more callers as defined in the Web IDL specification [WEBIDL].

2.4. Grammatical Concepts

The Augmented Backus-Naur Form (ABNF) notation used in this document is specified in RFC5234. [ABNF]

This document also uses the ABNF extension "#rule" as defined in Section 7 of HTTP/1.1 -- Message Syntax and Routing. [RFC7230]

The following core rules are included by reference, as defined in Appendix B.1 of [ABNF]: ALPHA (letters), DIGIT (decimal 0-9), WSP (white space) and VCHAR (printing characters).

3. Policy Delivery

The server delivers a policy to the user agent via an HTTP response header (defined in §3.1 Content-Security-Policy Header Field and §3.2 Content-Security-Policy-Report-Only Header Field ) or an HTML meta element (defined in §3.3 HTML meta Element ).

Servers are informed that requests are coming from a protected resource via an HTTP request header (defined in §3.4 The CSP HTTP Request Header).

3.1. `Content-Security-Policy` Header Field

The Content-Security-Policy header field is the preferred mechanism for delivering a policy. The grammar is as follows:

"Content-Security-Policy:" 1#policy-token

For example, a response might include the following header field:

Content-Security-Policy: script-src 'self'

A server MUST NOT send more than one HTTP header field named Content-Security-Policy with a given resource representation.

A server MAY send different Content-Security-Policy header field values with different representations of the same resource or with different resources.

Upon receiving an HTTP response containing at least one Content-Security-Policy header field, the user agent MUST enforce each of the policies contained in each such header field.

3.2. `Content-Security-Policy-Report-Only` Header Field

The Content-Security-Policy-Report-Only header field lets servers experiment with policies by monitoring (rather than enforcing) a policy. The grammar is as follows:

"Content-Security-Policy-Report-Only:" 1#policy-token

For example, server operators might wish to develop their security policy iteratively. The operators can deploy a report-only policy based on their best estimate of how their site behaves:

Content-Security-Policy-Report-Only: script-src 'self';
                                     report-uri /csp-report-endpoint/

If their site violates this policy the user agent will send violation reports to the URL specified in the policy’s report-uri directive, but allow the violating resources to load regardless. Once a site has confidence that the policy is appropriate, they can start enforcing the policy using the Content-Security-Policy header field.

A server MUST NOT send more than one HTTP header field named Content-Security-Policy-Report-Only with a given resource representation.

A server MAY send different Content-Security-Policy-Report-Only header field values with different representations of the same resource or with different resources.

Upon receiving an HTTP response containing at least one Content-Security-Policy-Report-Only header field, the user agent MUST monitor each of the policies contained in each such header field.

Note: The Content-Security-Policy-Report-Only header is not supported inside a meta element.

3.3. HTML `meta` Element

The server MAY supply policy via one or more HTML meta elements with http-equiv attributes that are an ASCII case-insensitive match for the string "Content-Security-Policy". For example:

<meta http-equiv="Content-Security-Policy" content="script-src 'self'">

Add the following entry to the pragma directives for the meta element:

Content security policy (http-equiv="content-security-policy")

If the Document’s head element is not an ancestor of the meta element, abort these steps.
If the meta element lacks a content attribute, abort these steps.
Let policy be the value of the content attribute of the meta element.
Let directive-set be the result of parsing policy.
Remove all occurrences of report-uri, frame-ancestors, and sandbox directives from directive-set.
Note: User agents are encouraged to issue a warning to developers if one or more of these directives are included in a policy delivered via meta.
Enforce each of the directives in directive-set, as defined for each directive type.

Authors are strongly encouraged to place meta elements as early in the document as possible, because policies in meta elements are not applied to content which preceeds them. In particular, note that resources fetched or prefetched using the Link HTTP response header field, and resources fetched or prefetched using link and script elements which preceed a meta-delivered policy will not be blocked.

Note: A policy specified via a meta element will be enforced along with any other policies active for the protected resource, regardless of where they’re specified. The general impact of enforcing multiple policies is described in §3.5 Enforcing multiple policies..

Note: Modifications to the content attribute of a meta element after the element has been parsed will be ignored.

Note: The Content-Security-Policy-Report-Only header is not supported inside a meta element.

3.4. The `CSP` HTTP Request Header

The CSP header field indicates that a particular request is subject to a policy, and its value is defined by the following ABNF grammar:

"CSP:" 1#csp-header-value

csp-header-value = *WSP "active" *WSP

If the user agent is monitoring or enforcing a policy that includes directives whose value is a source list, and whose source list contains the 'unsafe-redirect' source expression, then the user agent MUST send a header field named CSP along with requests for resources whose origin does not match the protected resource’s origin. The value of this header MUST be active.

The user agent MAY choose to send this header only if the request is for a resource type which the active policy would effect. That is, given a policy of img-src example.com 'unsafe-redirect', the user agent would send CSP: active along with requests for images, but might choose not to send the header with requests for script.

Note: The central reason for including this header is that it hints to a server that information about redirects might be leaked as a side-effect of a page’s active policy. If this header is present, a server might decline to redirect a logged-out user from example.com to accounts.example.com, for example, as a malicious embedder might otherwise be able to determine the user’s logged-in status.

3.5. Enforcing multiple policies.

This section is not normative.

The above sections note that when multiple policies are present, each must be enforced or reported, according to its type. An example will help clarify how that ought to work in practice. The behavior of an XMLHttpRequest might seem unclear given a site that, for whatever reason, delivered the following HTTP headers:

Content-Security-Policy: default-src 'self' http://example.com http://example.net;
                         connect-src 'none';
Content-Security-Policy: connect-src http://example.com/;
                         script-src http://example.com/

Is a connection to example.com allowed or not? The short answer is that the connection is not allowed. Enforcing both policies means that a potential connection would have to pass through both unscathed. Even though the second policy would allow this connection, the first policy contains connect-src 'none', so its enforcement blocks the connection. The impact is that adding additional policies to the list of policies to enforce can only further restrict the capabilities of the protected resource.

To demonstrate that further, consider a script tag on this page. The first policy would lock scripts down to 'self', http://example.com and http://example.net via the default-src directive. The second, however, would only allow script from http://example.com/. Script will only load if it meets both policy’s criteria: in this case, the only origin that can match is http://example.com, as both policies allow it.

3.6. Policy applicability

This section is not normative.

Policies are associated with an protected resource, and enforced or monitored for that resource. If a resource does not create a new execution context (for example, when including a script, image, or stylesheet into a document), then any policies delivered with that resource are discarded without effect. Its execution is subject to the policy or policies of the including context. The following table outlines examples of these relationships:

Resource Type		What policy applies?
Top-level Contexts	HTML as a new, top-level browsing context	The policy delivered with the resource
Top-level Contexts	SVG, as a top-level document	Policy delivered with the resource
Embedded Contexts	Any resource included via `iframe`, `object`, or `embed`	The policy of the embedding resource controls what may be embedded. The embedded resource, however, is controlled by the policy delivered with the resource, or the policy of the embedding resource if the embedded resource is a globally unique identifier (or a `srcdoc` frame).
	SVG, as an embedded document	The policy delivered with the resource, or policy of the creating context if created from a globally unique identifier.
	JavaScript, as a Worker, Shared Worker or Service Worker	The policy delivered with the resource, or policy of the creating context if created from a globally unique identifier
Subresources	SVG, inlined via `svg`	Policy of the including context
	SVG, as a resource document	Policy of the including context
	HTML via XMLHttpRequest	Policy of the context that performed the fetch
	Image via `img` element	Policy of the including context
	JavaScript via a `script` element	Policy of the including context
	SVG, via `img`	No policy; should be just as safe as JPG
	SVG, as a WebFont	No policy; should be just as safe as WOFF

4. Syntax and Algorithms

4.1. Policy Syntax

A Content Security Policy consists of a U+003B SEMICOLON (;) delimited list of directives. Each directive consists of a directive name and (optionally) a directive value, defined by the following ABNF:

policy-token    = [ directive-token *( ";" [ directive-token ] ) ]
directive-token = *WSP [ directive-name [ WSP directive-value ] ]
directive-name  = 1*( ALPHA / DIGIT / "-" )
directive-value = *( WSP / <VCHAR except ";" and ","> )

4.1.1. Parsing Policies

To parse the policy policy, the user agent MUST use an algorithm equivalent to the following:

Let the set of directives be the empty set.
For each non-empty token returned by strictly splitting the string policy on the character U+003B SEMICOLON (;):
1. Skip whitespace.
2. Collect a sequence of characters that are not space characters. The collected characters are the directive name.
3. If there are characters remaining in token, skip ahead exactly one character (which must be a space character).
4. The remaining characters in token (if any) are the directive value.
5. If the set of directives already contains a directive whose name is a case insensitive match for directive name, ignore this instance of the directive and continue to the next token.
6. Add a directive to the set of directives with name directive name and value directive value.
Return the set of directives.

4.2. Source List Syntax

Many CSP directives use a value consisting of a source list, defined in the ABNF grammar below.

Each source expression in the source list represents a location from which content of the specified type can be retrieved. For example, the source expression 'none' represents the empty set of URLs, and the source expression 'unsafe-inline' represents content supplied inline in the resource itself.

source-list       = *WSP [ source-expression *( 1*WSP source-expression ) *WSP ]
                  / *WSP "'none'" *WSP
source-expression = scheme-source / host-source / keyword-source / nonce-source / hash-source
scheme-source     = scheme-part ":"
host-source       = [ scheme-part "://" ] host-part [ port-part ] [ path-part ]
keyword-source    = "'self'" / "'unsafe-inline'" / "'unsafe-eval'" / "'unsafe-redirect'"
base64-value      = 1*( ALPHA / DIGIT / "+" / "/" )*2( "=" )
nonce-value       = base64-value
hash-value        = base64-value
nonce-source      = "'nonce-" nonce-value "'"
hash-algo         = "sha256" / "sha384" / "sha512"
hash-source       = "'" hash-algo "-" hash-value "'"
scheme-part       = <scheme production from RFC 3986, section 3.1>
host-part         = "*" / [ "*." ] 1*host-char *( "." 1*host-char )
host-char         = ALPHA / DIGIT / "-"
path-part         = <path production from RFC 3986, section 3.3>
port-part         = ":" ( 1*DIGIT / "*" )

If the policy contains a nonce-source expression, the server MUST generate a fresh value for the nonce-value directive at random and independently each time it transmits a policy. The generated value SHOULD be at least 128 bits long (before encoding), and generated via a cryptographically secure random number generator. This requirement ensures that the nonce-value is difficult for an attacker to predict.

Note: Using a nonce to whitelist inline script or style is less secure than not using a nonce, as nonces override the restrictions in the directive in which they are present. An attacker who can gain access to the nonce can execute whatever script they like, whenever they like. That said, nonces provide a substantial improvement over 'unsafe-inline' when layering a content security policy on top of old code. When considering 'unsafe-inline', authors are encouraged to consider nonces (or hashes) instead.

The host-char production intentionally contains only ASCII characters; internationalized domain names cannot be entered directly into a policy string, but instead MUST be Punycode-encoded [RFC3492]. For example, the domain üüüüüü.de would be encoded as xn--tdaaaaaa.de.

NOTE: Though IP addresses do match the grammar above, only 127.0.0.1 will actually match a URL when used in a source expression (see §4.2.2 Matching Source Expressions for details). The security properties of IP addresses are suspect, and authors ought to prefer hostnames to IP addresses whenever possible.

4.2.1. Parsing Source Lists

To parse a source list source list, the user agent MUST use an algorithm equivalent to the following:

Strip leading and trailing whitespace from source list.
If source list is an ASCII case-insensitive match for the string 'none' (including the quotation marks), return the empty set.
Let set of source expressions be the empty set.
For each token returned by splitting source list on spaces, if the token matches the grammar for source-expression, add the token to the set of source expressions.
Return the set of source expressions.

Note: Characters like U+003B SEMICOLON (;) and U+002C COMMA (,) cannot appear in source expressions directly: if you’d like to include these characters in a source expression, they must be percent encoded as %3B and %2C respectively.

4.2.2. Matching Source Expressions

A URL url is said to match a source expression for a protected resource if the following algorithm returns does match:

Let url be the result of processing the URL through the URL parser.
If the source expression a consists of a single U+002A ASTERISK character (*), and url’s scheme is not one of blob, data, filesystem, then return does match.
If the source expression matches the grammar for scheme-source:
1. If url’s scheme is an ASCII case-insensitive match for the source expression’s scheme-part, return does match.
2. Otherwise, return does not match.
If the source expression matches the grammar for host-source:
1. If url’s host is null, return does not match.
2. Let url-scheme, url-host, and url-port be the scheme, host, and port of url’s origin, respectively.
  Note: If url doesn’t specify a port, then its origin’s port will be the default port for url’s scheme.
3. Let url-path-list be the path of url.
4. If the source expression has a scheme-part that is not a case insensitive match for url-scheme, then return does not match.
5. If the source expression does not have a scheme, return does not match if any of the following are true:
  1. the scheme of the protected resource’s URL is a case insensitive match for HTTP, and url-scheme is not a case insensitive match for either HTTP or HTTPS
  2. the scheme of the protected resource’s URL is not a case insensitive match for HTTP, and url-scheme is not a case insensitive match for the scheme of the protected resource’s URL.
6. If the first character of the source expression’s host-part is an U+002A ASTERISK character (*) and the remaining characters, including the leading U+002E FULL STOP character (.), are not a case insensitive match for the rightmost characters of url-host, then return does not match.
7. If the first character of the source expression’s host-part is not an U+002A ASTERISK character (*) and url-host is not a case insensitive match for the source expression’s host-part, then return does not match.
8. If the source expression’s host-part matches the IPv4address production from [RFC3986], and is not 127.0.0.1, or is an IPv6 address, return does not match.
  Note: A future version of this specification may allow literal IPv6 and IPv4 addresses, depending on usage and demand. Given the weak security properties of IP addresses in relation to named hosts, however, authors are encouraged to prefer the latter whenever possible.
9. If the source expression does not contain a port-part and url-port is not the default port for url-scheme, then return does not match.
10. If the source expression does contain a port-part, then return does not match if both of the following are true:
  1. port-part does not contain an U+002A ASTERISK character (*)
  2. port-part does not represent the same number as url-port
11. If the source expression contains a non-empty path-part, and the URL is not the result of a redirect, then:
  1. Let exact-match be true if the final character of path-part is not the U+002F SOLIDUS character (/), and false otherwise.
  2. Let source-expression-path-list be the result of splitting path-part on the U+002F SOLIDUS character (/).
  3. If source-expression-path-list’s length is greater than url-path-list’s length, return does not match.
  4. For each entry in source-expression-path-list:
    1. Percent decode entry.
    2. Percent decode the first item in url-path-list.
    3. If entry is not an ASCII case-insensitive match for the first item in url-path-list, return does not match.
    4. Pop the first item in url-path-list off the list.
  5. If exact-match is true, and url-path-list is not empty, return does not match.
12. Otherwise, return does match.
If the source expression is a case insensitive match for 'self' (including the quotation marks), then:
1. Return does match if the origin of url matches the origin of protected resource’s URL.
  Note: This includes IP addresses. That is, a document at https://111.111.111.111/ with a policy of img-src 'self' can load the image https://111.111.111.111/image.png, as the origins match.
Otherwise, return does not match.

Note: This algorithm treats the URLs https://example.com/ and https://example.com./ as non-matching. This is consistent with browser behavior which treats documents served from these URLs as existing in distinct origins.

A URL url is said to match a source list for protected resource if the following conditions are met:

At least one source expression in the set of source expressions obtained by parsing the source list matches url for protected resource.
At least one of the following is true:
1. url is not the result of a redirect.
  Note: This is a bit hand-wavey; in the future, CSP will cleanly integrate with [FETCH], which will allow us to clarify the details.
2. The set of source expressions obtained by parsing the source list contains the source expression 'unsafe-redirect'.
3. The source list is the U+002A ASTERISK character (*).

Note: No URLs match an empty set of source expressions, such as the set obtained by parsing the source list 'none'.

4.2.2.1. Security Considerations for GUID URL schemes

This section is not normative.

As defined above, special URL schemes that refer to specific pieces of unique content, such as "data:", "blob:" and "filesystem:" are excluded from matching a policy of * and must be explicitly listed. Policy authors should note that the content of such URLs is often derived from a response body or execution in a Document context, which may be unsafe. Especially for the default-src and script-src directives, policy authors should be aware that allowing "data:" URLs is equivalent to unsafe-inline and allowing "blob:" or "filesystem:" URLs is equivalent to unsafe-eval.

4.2.2.2. Path Matching

This section is not normative.

The rules for matching source expressions that contain paths are simpler than they look: paths that end with the '/' character match all files in a directory and its subdirectories. Paths that do not end with the '/' character match only one specific file. A few examples should make this clear:

The source expression example.com has no path, and therefore matches any file served from that host.
The source expression example.com/scripts/ matches any file in the scripts directory of example.com, and any of its subdirectories. For example, both https://example.com/scripts/file.js and https://example.com/scripts/js/file.js would match.
The source expression example.com/scripts/file.js matches only the file named file.js in the scripts directory of example.com.
Likewise, the source expression example.com/js matches only the file named js. In particular, note that it would not match files inside a directory named js. Files like example.com/js/file.js would be matched only if the source expression ended with a trailing "/", as in example.com/js/.

Note: Query strings have no impact on matching: the source expression example.com/file matches all of https://example.com/file, https://example.com/file?key=value, https://example.com/file?key=notvalue, and https://example.com/file?notkey=notvalue.

4.2.2.3. Paths and Redirects

To avoid leaking path information cross-origin (as discussed in Egor Homakov’s Using Content-Security-Policy for Evil), the matching algorithm ignores the path component of a source expression if the resource being loaded is the result of a redirect. For example, given a page with an active policy of img-src example.com not-example.com/path:

Directly loading https://not-example.com/not-path would fail, as it doesn’t match the policy.
Directly loading https://example.com/redirector would pass, as it matches example.com.
Assuming that https://example.com/redirector delivered a redirect response pointing to https://not-example.com/not-path, the load would succeed, as the initial URL matches example.com, and the redirect target matches not-example.com/path if we ignore its path component.

This restriction reduces the granularity of a document’s policy when redirects are in play, which isn’t wonderful, but given that we certainly don’t want to allow brute-forcing paths after redirects, it seems a reasonable compromise.

The relatively long thread "Remove paths from CSP?" from public-webappsec@w3.org has more detailed discussion around alternate proposals.

4.2.3. The `nonce` attribute

Nonce sources require a new nonce attribute to be added to both script and style elements.

partial interface HTMLScriptElement {
  attribute DOMString nonce;
};

nonce, of type DOMString: This attribute reflects the value of the element’s nonce content attribute.

partial interface HTMLStyleElement {
  attribute DOMString nonce;
};

nonce, of type DOMString: This attribute reflects the value of the element’s nonce content attribute.

4.2.4. Valid Nonces

An element has a valid nonce for a set of source expressions if the value of the element’s nonce attribute after stripping leading and trailing whitespace is a case-sensitive match for the nonce-value component of at least one nonce-source expression in set of source expressions.

4.2.5. Valid Hashes

An element’s content is the script block’s source for script elements, or the value of the element’s textContent IDL attribute for non-script elements such as style.

The digest of element’s content for is the result of applying an algorithm to the element’s content.

To determine whether element has a valid hash for a set of source expressions, execute the following steps:

Let hashes be a list of all hash-source expressions in set of source expressions.
For each hash in hashes:
1. Let algorithm be:
  - SHA-256 if the hash-algo component of hash is an ASCII case-insensitive match for the string "sha256"
  - SHA-384 if the hash-algo component of hash is an ASCII case-insensitive match for the string "sha384"
  - SHA-512 if the hash-algo component of hash is an ASCII case-insensitive match for the string "sha512"
2. Let expected be the hash-value component of hash.
3. Let actual be the base64 encoding of the binary digest of element’s content using the algorithm algorithm.
4. If actual is a case-sensitive match for expected, return true and abort these steps.
Return false.

Note: If an element has an invalid hash, it would be helpful if the user agent reported the failure to the author by adding a warning message containing the actual hash value.

4.3. Media Type List Syntax

The plugin-types directive uses a value consisting of a media type list.

Each media type in the media type list represents a specific type of resource that can be retrieved and used to instantiate a plugin in the protected resource.

media-type-list   = media-type *( 1*WSP media-type )
media-type        = <type from RFC 2045> "/" <subtype from RFC 2045>

4.3.1. Parsing

To parse a media type list media type list, the user agent MUST use an algorithm equivalent to the following:

Let the set of media types be the empty set.
For each token returned by splitting media type list on spaces, if the token matches the grammar for media-type, add the token to the set of media types. Otherwise ignore the token.
Return the set of media types.

4.3.2. Matching

A media type matches a media type list if, and only if, the media type is an ASCII case-insensitive match for at least one token in the set of media types obtained by parsing the media type list.

4.4. Reporting

To strip uri for reporting, the user agent MUST use an algorithm equivalent to the following:

If the origin of uri is a globally unique identifier (for example, uri has a scheme of data, blob, or filesystem), then abort these steps, and return the ASCII serialization of uri’s scheme.
If the origin of uri is not the same as the origin of the protected resource, then abort these steps, and return the ASCII serialization of uri’s origin.
Return uri, with any fragment component removed.

To generate a violation report object, the user agent MUST use an algorithm equivalent to the following:

Prepare a JSON object violation with the following keys and values:

blocked-uri
The originally requested URL of the resource that was prevented from loading, stripped for reporting, or the empty string if the resource has no URL (inline script and inline style, for example).
document-uri
The address of the protected resource, stripped for reporting.
effective-directive
The name of the policy directive that was violated. This will contain the directive whose enforcement triggered the violation (e.g. "script-src") even if that directive does not explicitly appear in the policy, but is implicitly activated via the default-src directive.
original-policy
The original policy, as received by the user agent.
referrer
The referrer attribute of the protected resource, or the empty string if the protected resource has no referrer.
status-code
The status-code of the HTTP response that contained the protected resource, if the protected resource was obtained over HTTP. Otherwise, the number 0.
violated-directive
The policy directive that was violated, as it appears in the policy. This will contain the default-src directive in the case of violations caused by falling back to the default sources when enforcing a directive.
If a specific line or a specific file can be identified as the cause of the violation (for example, script execution that violates the script-src directive), the user agent MAY add the following keys and values to violation:

source-file
The URL of the resource where the violation occurred, stripped for reporting.
line-number
The line number in source-file on which the violation occurred.
column-number
The column number in source-file on which the violation occurred.
Return violation.

Note: blocked-uri will not contain the final location of a resource that was blocked after one or more redirects. It instead will contain only the location that the protected resource requested, before any redirects were followed.

To send violation reports, the user agent MUST use an algorithm equivalent to the following:

Prepare a JSON object report object with a single key, csp-report, whose value is the result of generating a violation report object.
Let report body be the JSON stringification of report object.
For each report URL in the set of report URLs:
1. If the user agent has already sent a violation report for the protected resource to report URL, and that report contained an entity body that exactly matches report body, the user agent MAY abort these steps and continue to the next report URL.
2. Queue a task to fetch report URL from the origin of the protected resource, with the synchronous flag not set, using HTTP method POST, with a Content-Type header field of application/csp-report, and an entity body consisting of report body. If the origin of report URL is not the same as the origin of the protected resource, the block cookies flag MUST also be set. The user agent MUST NOT follow redirects when fetching this resource. (Note: The user agent ignores the fetched resource.) The task source for these tasks is the Content Security Policy task source.

To report a violation, the user agent MUST:

Fire a violation event at the protected resource’s Document.
If the set of report URLs is non-empty, send violation reports to each.

Note: This section of the specification should not be interpreted as limiting user agents' ability to apply restrictions to violation reports in order to limit data leakage above and beyond what these algorithms specify. For example, a user agent might offer users the option of disabling reporting entirely.

5. Processing Model

To enforce a policy, the user agent MUST parse the policy and enforce each of the directives contained in the policy, where the specific requirements for enforcing each directive are defined separately for each directive (See §7 Directives, below).

Generally speaking, enforcing a directive prevents the protected resource from performing certain actions, such as loading scripts from URLs other than those indicated in a source list. These restrictions make it more difficult for an attacker to abuse an injection vulnerability in the resource because the attacker will be unable to usurp the resource’s privileges that have been restricted in this way.

Note: User agents may allow users to modify or bypass policy enforcement through user preferences, bookmarklets, third-party additions to the user agent, and other such mechanisms.

To monitor a policy, the user agent MUST parse the policy and monitor each of the directives contained in the policy.

Monitoring a directive does not prevent the protected resource from undertaking any actions. Instead, any actions that would have been prevented by the directives are allowed, but a violation report is generated and reported to the developer of the web application. Monitoring a policy is useful for testing whether enforcing the policy will cause the web application to malfunction.

A server MAY cause user agents to monitor one policy while enforcing another policy by returning both Content-Security-Policy and Content-Security-Policy-Report-Only header fields. For example, if a server operator may wish to enforce one policy but experiment with a stricter policy, she can monitor the stricter policy while enforcing the original policy. Once the server operator is satisfied that the stricter policy does not break the web application, the server operator can start enforcing the stricter policy.

If the user agent monitors or enforces a policy that does not contain any directives, the user agent SHOULD report a warning message in the developer console.

If the user agent monitors or enforces a policy that contains an unrecognized directive, the user agent SHOULD report a warning message in the developer console indicating the name of the unrecognized directive.

If the user agent monitors or enforces a policy that contains a directive that contains a source list, then the user agent MUST set a CSP Request Header when requesting cross-origin resources, as described in §3.4 The CSP HTTP Request Header.

5.1. Workers

Whenever a user agent runs a worker:

If the worker’s script’s origin is a globally unique identifier (for example, the worker’s script’s URL has a scheme of data, blob, or filesystem), then:
- If the user agent is enforcing a CSP policy for the owner document or parent worker, the user agent MUST enforce the CSP policy for the worker.
- If the user agent is monitoring a CSP policy for the owner document or parent worker, the user agent MUST monitor the CSP policy for the worker.
Otherwise:
- If the worker’s script is delivered with a Content-Security-Policy HTTP header containing the value policy, the user agent MUST enforce policy for the worker.
- If the worker’s script is delivered with a Content-Security-Policy-Report-Only HTTP header containing the value policy, the user agent MUST monitor policy for the worker.

5.2. `srcdoc` IFrames

Whenever a user agent creates an iframe srcdoc document in a browsing context nested in the protected resource, if the user agent is enforcing any policies for the protected resource, the user agent MUST enforce those policies on the iframe srcdoc document as well.

Whenever a user agent creates an iframe srcdoc document in a browsing context nested in the protected resource, if the user agent is monitoring any policies for the protected resource, the user agent MUST monitor those policies on the iframe srcdoc document as well.

6. Script Interfaces

6.1. `SecurityPolicyViolationEvent` Interface

[Constructor(DOMString type, optional SecurityPolicyViolationEventInit eventInitDict)]
interface SecurityPolicyViolationEvent : Event {
    readonly    attribute DOMString documentURI;
    readonly    attribute DOMString referrer;
    readonly    attribute DOMString blockedURI;
    readonly    attribute DOMString violatedDirective;
    readonly    attribute DOMString effectiveDirective;
    readonly    attribute DOMString originalPolicy;
    readonly    attribute DOMString sourceFile;
    readonly    attribute DOMString statusCode;
    readonly    attribute long      lineNumber;
    readonly    attribute long      columnNumber;
};

documentURI, of type DOMString, readonly: Refer to the document-uri property of violation reports for a description of this property.
referrer, of type DOMString, readonly: Refer to the referrer property of violation reports for a description of this property.
blockedURI, of type DOMString, readonly: Refer to the blocked-uri property of violation reports for a description of this property.
violatedDirective, of type DOMString, readonly: Refer to the violated-directive property of violation reports for a description of this property.
effectiveDirective, of type DOMString, readonly: Refer to the effective-directive property of violation reports for a description of this property.
originalPolicy, of type DOMString, readonly: Refer to the original-policy property of violation reports for a description of this property.
statusCode, of type DOMString, readonly: Refer to the status-code property of violation reports for a description of this property.
sourceFile, of type DOMString, readonly: Refer to the source-file property of violation reports for a description of this property.
lineNumber, of type long, readonly: Refer to the line-number property of violation reports for a description of this property.
columnNumber, of type long, readonly: Refer to the column-number property of violation reports for a description of this property.

6.2. `SecurityPolicyViolationEventInit` Interface

dictionary SecurityPolicyViolationEventInit : EventInit {
    DOMString documentURI;
    DOMString referrer;
    DOMString blockedURI;
    DOMString violatedDirective;
    DOMString effectiveDirective;
    DOMString originalPolicy;
    DOMString sourceFile;
    long      lineNumber;
    long      columnNumber;
};

documentURI, of type DOMString: Refer to the document-uri property of violation reports for a description of this property.
referrer, of type DOMString: Refer to the referrer property of violation reports for a description of this property.
blockedURI, of type DOMString: Refer to the blocked-uri property of violation reports for a description of this property.
violatedDirective, of type DOMString: Refer to the violated-directive property of violation reports for a description of this property.
effectiveDirective, of type DOMString: Refer to the effective-directive property of violation reports for a description of this property.
originalPolicy, of type DOMString: Refer to the original-policy property of violation reports for a description of this property.
sourceFile, of type DOMString: Refer to the source-file property of violation reports for a description of this property.
lineNumber, of type long: Refer to the line-number property of violation reports for a description of this property.
columnNumber, of type long: Refer to the column-number property of violation reports for a description of this property.

6.3. Firing Violation Events

To fire a violation event, the user agent MUST use an algorithm equivalent to the following:

Let report object be the result of generating a violation report object.
Queue a task to fire an event named securitypolicyviolation using the SecurityPolicyViolationEvent interface with the following initializations:
- blockedURI MUST be initialized to the value of report object’s blocked-uri key.
- documentURI MUST be initialized to the value of report object’s document-uri key.
- effectiveDirective MUST be initialized to the value of report object’s effective-directive key.
- originalPolicy MUST be initialized to the value of report object’s original-policy key.
- referrer MUST be initialized to the value of report object’s referrer key.
- violatedDirective MUST be initialized to the value of report object’s violated-directive key.
- sourceFile MUST be initialized to the value of report object’s source-file key.
- lineNumber MUST be initialized to the value of report object’s line-number key.
- columnNumber MUST be initialized to the value of report object’s column-number key.

The task source for these tasks is the Content Security Policy task source.

7. Directives

This section describes the content security policy directives introduced in this specification. Directive names are case insensitive.

In order to protect against Cross-Site Scripting (XSS), web application authors SHOULD include:

both the script-src and object-src directives, or
include a default-src directive, which covers both scripts and plugins.

In either case, authors SHOULD NOT include either 'unsafe-inline' or data: as valid sources in their policies. Both enable XSS attacks by allowing code to be included directly in the document itself; they are best avoided completely.

Redirects are another area of potential concern. Authors SHOULD NOT include 'unsafe-redirect' as valid sources in their policies. It makes it more difficult to reason about the complete set of resources that a policy allows, especially given the path behavior outlined in the §4.2.2.3 Paths and Redirects section.

7.1. `base-uri`

The base-uri directive restricts the URLs that can be used to specify the document base URL. The syntax for the name and value of the directive are described by the following ABNF grammar:

directive-name    = "base-uri"
directive-value   = source-list

The term allowed base URLs refers to the result of parsing the base-uri directive’s value as a source list.

Note: base-uri does not fall back to the default sources.

Step 4 of the algorithm defined in HTML5 to obtain a document’s base URL MUST be changed to:

If the previous step was not successful, or the result of the previous step does not match the allowed base URLs for the protected resource, then the document base URL is fallback base URL. Otherwise, it is the result of the previous step.

7.2. `child-src`

The child-src directive governs the creation of nested browsing contexts as well as Worker execution contexts. The syntax for the name and value of the directive are described by the following ABNF grammar:

directive-name    = "child-src"
directive-value   = source-list

The term allowed child sources refers to the result of parsing the child-src directive’s value as a source list if a child-src directive is explicitly specified, and otherwise to the default sources.

7.2.1. Nested Browsing Contexts

To enforce the child-src directive the user agent MUST enforce the frame-src directive.

7.2.2. Workers

Whenever the user agent fetches a URL while processing the Worker or SharedWorker constructors [WORKERS], the user agent MUST act as if there was a fatal network error and no resource was obtained, and report a violation if the URL does not match the allowed child sources for the protected resource.

7.3. `connect-src`

The connect-src directive restricts which URLs the protected resource can load using script interfaces. The syntax for the name and value of the directive are described by the following ABNF grammar:

directive-name    = "connect-src"
directive-value   = source-list

The term allowed connection targets refers to the result of parsing the connect-src directive’s value as a source list if the policy contains an explicit connect-src directive, or otherwise to the default sources.

Whenever the user agent fetches a URL in the course of one of the following activities, if the URL does not match the allowed connection targets for the protected resource, the user agent MUST act as if there was a fatal network error and no resource was obtained, and report a violation:

Processing the send() method of an XMLHttpRequest object.
Processing the WebSocket constructor.
Processing the EventSource constructor.
Pinging an endpoint during hyperlink auditing.
Sending a beacon via the sendBeacon() method [BEACON]

7.3.1. Usage

This section is not normative.

JavaScript offers a few mechanisms that directly connect to an external server to send or receive information. EventSource maintains an open HTTP connection to a server in order to receive push notifications, WebSockets open a bidirectional communication channel between your browser and a server, and XMLHttpRequest makes arbitrary HTTP requests on your behalf. These are powerful APIs that enable useful functionality, but also provide tempting avenues for data exfiltration.

The connect-src directive allows you to ensure that these sorts of connections are only opened to origins you trust. Sending a policy that defines a list of source expressions for this directive is straightforward. For example, to limit connections to only example.com, send the following header:

Content-Security-Policy: connect-src example.com

All of the following will fail with the preceding directive in place:

new WebSocket("wss://evil.com/");
(new XMLHttpRequest()).open("GET", "https://evil.com/", true);
new EventSource("https://evil.com");

7.4. `default-src`

The default-src directive sets a default source list for a number of directives. The syntax for the name and value of the directive are described by the following ABNF grammar:

directive-name    = "default-src"
directive-value   = source-list

Let the default sources be the result of parsing the default-src directive’s value as a source list if a default-src directive is explicitly specified, and otherwise the U+002A ASTERISK character (*).

To enforce the default-src directive, the user agent MUST enforce the following directives:

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

If not specified explicitly in the policy, the directives listed above will use the default sources as their source list.

7.4.1. Usage

This section is not normative.

default-src, as the name implies, serves as a default source list which the other source list-style directives will use as a fallback if they’re not otherwise explicitly set. That is, consider the following policy declaration:

Content-Security-Policy: default-src 'self'

Under this policy, fonts, frames, images, media, objects, scripts, and styles will all only load from the same origin as the protected resource, and connections will only be made to the same origin. Adding a more specific declaration to the policy would completely override the default source list for that resource type.

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

Under this new policy, fonts, frames, and etc. continue to be load from the same origin, but scripts will only load from example.com. There’s no inheritance; the script-src directive sets the allowed sources of script, and the default list is not used for that resource type.

Given this behavior, one good way of building a policy for a site would be to begin with a default-src of 'none', and to build up a policy from there that contains only those resource types which are actually in use for the page you’d like to protect. If you don’t use webfonts, for instance, there’s no reason to specify a source list for font-src; specifying only those resource types a page uses ensures that the possible attack surface for that page remains as small as possible.

7.5. `font-src`

The font-src directive restricts from where the protected resource can load fonts. The syntax for the name and value of the directive are described by the following ABNF grammar:

directive-name    = "font-src"
directive-value   = source-list

The term allowed font sources refers to the result of parsing the font-src directive’s value as a source list if the policy contains an explicit font-src, or otherwise to the default sources.

Whenever the user agent fetches a URL in the course of one of the following activities, if the URL does not match the allowed font sources for the protected resource, the user agent MUST act as if there was a fatal network error and no resource was obtained, and report a violation:

Requesting data for display in a font, such as when processing the <@font-face> Cascading Style Sheets (CSS) rule.

7.6. `form-action`

The form-action restricts which URLs can be used as the action of HTML form elements. The syntax for the name and value of the directive are described by the following ABNF grammar:

directive-name    = "form-action"
directive-value   = source-list

The term allowed form actions refers to the result of parsing the form-action directive’s value as a source list.

Whenever the user agent fetches a URL in the course of processing an HTML form element, if the URL does not match the allowed form actions for the protected resource, the user agent MUST act as if there was a fatal network error and no resource was obtained, and report a violation.

Note: form-action does not fall back to the default sources when the directive is not defined. That is, a policy that defines default-src 'none' but not form-action will still allow form submissions to any target.

7.7. `frame-ancestors`

The frame-ancestors directive indicates whether the user agent should allow embedding the resource using a frame, iframe, object, embed or applet element, or equivalent functionality in non-HTML resources. Resources can use this directive to avoid many UI Redressing [UIREDRESS] attacks by avoiding being embedded into potentially hostile contexts.

The syntax for the name and value of the directive are described by the following ABNF grammar:

ancestor-source-list = [ ancestor-source *( 1*WSP ancestor-source ) ] / "'none'"
ancestor-source      = scheme-source / host-source

directive-name  = "frame-ancestors"
directive-value = ancestor-source-list

The term allowed frame ancestors refers to the result of parsing the frame-ancestors directive’s value as a source list. If a frame-ancestors directive is not explicitly included in the policy, then allowed frame ancestors is "*".

To enforce the frame-ancestors directive, whenever the user agent would load the protected resource into a nested browsing context, the user agent MUST perform the following steps:

Let nestedContext be the nested browsing context into which the protected resource is being loaded.
Let ancestorList be the list of all ancestors of nestedContext.
For each ancestorContext in ancestorList:
1. Let document be ancestorContext’s active document.
2. If document’s URL does not match the allowed frame ancestors for the protected resource, the user agent MUST:
  1. Abort loading the protected resource.
  2. Take one of the following actions:
    1. Act as if it received an empty HTTP 200 response.
    2. Redirect the user to a friendly error page which provides the option of opening the blocked page in a new top-level browsing context.
  3. Parse a sandboxing directive using the empty string as the input and the newly created document’s forced sandboxing flag set as the output.
  4. Report a violation.
  5. Abort these steps.

Steps 3.2.2 and 3.2.3 ensure that the blocked frame appears to be a normal cross-origin document’s load. If these steps are ignored, leakage of a document’s policy state is possible.

The frame-ancestors directive MUST be ignored when monitoring a policy, and when a contained in a policy defined via a meta element.

Note: frame-ancestors does not fall back to the default sources when the directive is not defined. That is, a policy that defines default-src 'none' but not frame-ancestors will still allow the resource to be framed from anywhere.

When generating a violation report for a frame-ancestors violation, the user agent MUST NOT include the value of the embedding ancestor as a blocked-uri value unless it is same-origin with the protected resource, as disclosing the value of cross-origin ancestors is a violation of the Same-Origin Policy.

7.7.1. Relation to `X-Frame-Options`

This directive is similar to the X-Frame-Options header that several user agents have implemented. The 'none' source expression is roughly equivalent to that header’s DENY, 'self' to SAMEORIGIN, and so on. The major difference is that many user agents implement SAMEORIGIN such that it only matches against the top-level document’s location. This directive checks each ancestor. If any ancestor doesn’t match, the load is cancelled. [RFC7034]

The frame-ancestors directive obsoletes the X-Frame-Options header. If a resource has both policies, the frame-ancestors policy SHOULD be enforced and the X-Frame-Options policy SHOULD be ignored.

7.7.2. Multiple Host Source Values

This section is not normative.

Multiple source-list expressions are allowed in a single policy (in contrast to X-Frame-Options, which allows only one) to enable scenarios involving embedded application components that are multiple levels below the top-level browsing context.

Many common scenarios for permissioned embedding (e.g. embeddable payment, sharing or social apps) involve potentially many hundreds or thousands of valid source-list expressions, but it is strongly recommended against accommodating such scenarios with a static frame-ancestors directive listing multiple values. In such cases it is beneficial to generate this value dynamically, based on an HTTP Referer header or an explicitly passed-in value, to allow only the sources necessary for each given embedding of the resource.

Consider a service providing a payments application at https://payments/makeEmbedded. The service allows this resource to be embedded by both merchant Alice and merchant Bob, who compete with each other. Sending:

Content-Security-Policy: frame-ancestors https://alice https://bob

would allow Bob to re-frame Alice’s resource and create fraudulent clicks, perhaps discrediting Alice with her customers or the payments service. If the payments service used additional information (e.g. as part of a URL like https://payments/makeEmbedded?merchant=alice) to send individually-tailored headers listing only the source-list expressions needed by each merchant, this attack would be eliminated.

7.8. `frame-src`

The frame-src directive is deprecated. Authors who wish to govern nested browsing contexts SHOULD use the child-src directive instead.

The frame-src directive restricts from where the protected resource can embed frames. The syntax for the name and value of the directive are described by the following ABNF grammar:

directive-name    = "frame-src"
directive-value   = source-list

The term allowed frame sources refers to the result of parsing the frame-src directive’s value as a source list if the policy contains an explicit frame-src, or otherwise to the list of allowed child sources.

Whenever the user agent fetches a URL in the course of one of the following activities, if the URL does not match the allowed frame sources for the protected resource, the user agent MUST act as if there was a fatal network error and no resource was obtained, and report a violation:

Requesting data for display in a nested browsing context in the protected resource created by an iframe or a frame element.
Navigated such a nested browsing context.

7.9. `img-src`

The img-src directive restricts from where the protected resource can load images. The syntax for the name and value of the directive are described by the following ABNF grammar:

directive-name    = "img-src"
directive-value   = source-list

The term allowed image sources refers to the result of parsing the img-src directive’s value as a source list if the policy contains an explicit img-src, or otherwise to the list of default sources.

Whenever the user agent fetches a URL in the course of one of the following activities, if the URL does not match the allowed image sources for the protected resource, the user agent MUST act as if there was a fatal network error and no resource was obtained, and report a violation:

Requesting data for an image, such as when processing the src or srcset attributes of an img element, the src attribute of an input element with a type of image, the poster attribute of a video element, the url(), <image()> or <image-set()> values on any Cascading Style Sheets (CSS) property that is capable of loading an image [CSS4-IMAGES], or the href attribute of a link element with an image-related rel attribute, such as icon.

7.10. `media-src`

The media-src directive restricts from where the protected resource can load video, audio, and associated text tracks. The syntax for the name and value of the directive are described by the following ABNF grammar:

directive-name    = "media-src"
directive-value   = source-list

The term allowed media sources refers to the result of parsing the media-src directive’s value as a source list if the policy contains an explicit media-src, or otherwise to the list of default sources.

Whenever the user agent fetches a URL in the course of one of the following activities, if the URL does not match the allowed media sources for the protected resource, the user agent MUST act as if there was a fatal network error and no resource was obtained, and report a violation:

Requesting data for a video or audio clip, such as when processing the src attribute of a video, audio, source, or track element.

7.11. `object-src`

The object-src directive restricts from where the protected resource can load plugins. The syntax for the name and value of the directive are described by the following ABNF grammar:

directive-name    = "object-src"
directive-value   = source-list

The term allowed object sources refers to the result of parsing the object-src directive’s value as a source list if the policy contains an explicit object-src, or otherwise to the list of default sources.

Whenever the user agent fetches a URL in the course of one of the following activities, if the URL does not match the allowed object sources for the protected resource, the user agent MUST act as if there was a fatal network error and no resource was obtained, and report a violation:

Requesting data for a plugin, such as when processing the data attribute of an object element, the src attribute of an embed element, or the code or archive attributes of an applet element.
Requesting data for display in a nested browsing context in the protected resource created by an object or an embed element.
Navigating such a nested browsing context.

It is not required that the consumer of the element’s data be a plugin in order for the object-src directive to be enforced. Data for any object, embed, or applet element MUST match the allowed object sources in order to be fetched. This is true even when the element data is semantically equivalent to content which would otherwise be restricted by one of the other §7 Directives, such as an object element with a text/html MIME type.

Whenever the user agent would load a plugin without an associated URL (e.g., because the object element lacked a data attribute), if the protected resource’s URL does not match the allowed object sources for the protected resource, the user agent MUST NOT load the plugin.

7.12. `plugin-types`

The plugin-types directive restricts the set of plugins that can be invoked by the protected resource by limiting the types of resources that can be embedded. The syntax for the name and value of the directive are described by the following ABNF grammar:

directive-name    = "plugin-types"
directive-value   = media-type-list

The term allowed plugin media types refers to the result of parsing the plugin-types directive’s value as a media type list.

Whenever the user agent would instantiate a plugin to handle resource while enforcing the plugin-types directive, the user agent MUST instead act as though the plugin reported an error and report a violation if any of the following conditions hold:

The plugin is embedded into the protected resource via an object or embed element that does not explicitly declare a MIME type via a type attribute.
resource’s media type does not match the list of allowed plugin media types.
The plugin is embedded into the protected resource via an object or embed element, and the media type declared in the element’s type attribute is not an ASCII case-insensitive match for the resource’s media type.
The plugin is embedded into the protected resource via an applet element, and resource’s media type is not an ASCII case-insensitive match for application/x-java-applet.

Note: In any of these cases, acting as though the plugin reported an error will cause the user agent to display the fallback content.

Whenever the user agent creates a plugin document in a nested browsing context in the protected resource, if the user agent is enforcing any plugin-types directives for the protected resource, the user agent MUST enforce those plugin-types directives on the plugin document as well.

Whenever the user agent creates a plugin document in a nested browsing context in the protected resource, if the user agent is monitoring any plugin-types directives for the protected resource, the user agent MUST monitor those plugin-types directives on the plugin document as well.

7.12.1. Usage

This section is not normative.

The plugin-types directive whitelists a certain set of MIME types that can be embedded in a protected resource. For example, a site might want to ensure that PDF content loads, but that no other plugins can be instantiated. The following directive would satisfy that requirement:

Content-Security-Policy: plugin-types application/pdf

Resources embedded via an embed or object element delivered with an application/pdf content type would be rendered in the appropriate plugin; resources delivered with some other content type would be blocked. Multiple types can be specified, in any order. If the site decided to additionally allow Flash at some point in the future, it could do so with the following directive:

Content-Security-Policy: plugin-types application/pdf application/x-shockwave-flash

Note: Wildcards are not accepted in the plugin-types directive. Only the resource types explicitly listed in the directive will be allowed.

7.12.2. Predeclaration of expected media types

This section is not normative.

Enforcing the plugin-types directive requires that object and embed elements declare the expected media type of the resource they include via the type attribute. If an author expects to load a PDF, she could specify this as follows:

<object data="resource" type="application/pdf"></object>

If resource isn’t actually a PDF file, it won’t load. This prevents certain types of attacks that rely on serving content that unexpectedly invokes a plugin other than that which the author intended.

Note: resource will not load in this scenario even if its media type is otherwise whitelisted: resources will only load when their media type is whitelisted and matches the declared type in their containing element.

7.13. `report-uri`

The report-uri directive specifies a URL to which the user agent sends reports about policy violation. The syntax for the name and value of the directive are described by the following ABNF grammar:

directive-name    = "report-uri"
directive-value   = uri-reference *( 1*WSP uri-reference )
uri-reference     = <URI-reference from RFC 3986>

The set of report URLs is the value of the report-uri directive, each resolved relative to the protected resource’s URL.

The process of sending violation reports to the URLs specified in this directive’s value is defined in this document’s §4.4 Reporting section.

Note: The report-uri directive will be ignored if contained within a meta element.

7.14. `sandbox`

The sandbox directive specifies an HTML sandbox policy that the user agent applies to the protected resource. The syntax for the name and value of the directive are described by the following ABNF grammar:

directive-name    = "sandbox"
directive-value   = "" / sandbox-token *( 1*WSP sandbox-token )
sandbox-token     = <token from RFC 7230>

When enforcing the sandbox directive, the user agent MUST parse a sandboxing directive using the directive-value as the input and protected resource’s forced sandboxing flag set as the output. [HTML5]

The sandbox directive will be ignored when monitoring a policy, and when contained in a policy defined via a meta element. Moreover, this directive has no effect when monitored, and has no reporting requirements.

7.14.1. Sandboxing and Workers

When delivered via an HTTP header, a Content Security Policy may indicate that sandboxing flags ought to be applied to a JavaScript execution environment that is not a Document. Of particular interest is the script content intended for use as a Worker, Shared Worker, or Service Worker. Many of the sandboxing flags do not apply to such environments, but allow-scripts and allow-same-origin have special requirements.

When a resource is loaded while executing the runs a Worker algorithm, the user agent MUST act as if there was a fatal network error and no resource could be obtained if either of the following conditions holds:

The sandbox directive delivered with the resource does not contain the allow-scripts flag.
The sandbox directive delivered with the resource does not contain the allow-same-origin flag, and the creation of the new execution context requires it to be same-origin with its creating context.

7.14.2. Usage

This section is not normative.

HTML5 defines a sandbox attribute for iframe elements, intended to allow web authors to reduce the risk of including potentially untrusted content by imposing restrictions on that content’s abilities. When the attribute is set, the content is forced into a unique origin, prevented from submitting forms, running script, creating or navigating other browsing contexts, and prevented from running plugins. These restrictions can be loosened by setting certain flags as the attribute’s value.

The sandbox directive allows any resource, framed or not, to ask for the same sorts of restrictions to be applied to itself.

For example, a message board or email system might provide downloads of arbitrary attachments provided by other users. Attacks that rely on tricking a client into rendering one of these attachments could be mitigated by requesting that resources only be rendered in a very restrictive sandbox. Sending the sandbox directive with an empty value establishes such an environment:

Content-Security-Policy: sandbox

More trusted resources might be allowed to run in an environment with fewer restrictions by adding allow-* flags to the directive’s value. For example, you can allow a page that you trust to run script, while ensuring that it isn’t treated as same-origin with the rest of your site. This can be accomplished by sending the sandbox directive with the allow-scripts flag:

Content-Security-Policy: sandbox allow-scripts

The set of flags available to the CSP directive should match those available to the iframe attribute. Currently, those include:

Note: Like the rest of Content Security Policy, the sandbox directive is meant as a defense-in-depth. Web authors would be well-served to use it in addition to standard sniffing-mitigation and privilege-reduction techniques.

7.15. `script-src`

The script-src directive restricts which scripts the protected resource can execute. The directive also controls other resources, such as XSLT style sheets [XSLT], which can cause the user agent to execute script. The syntax for the name and value of the directive are described by the following ABNF grammar:

directive-name    = "script-src"
directive-value   = source-list

The term allowed script sources refers to the result of parsing the script-src directive’s value as a source list if the policy contains an explicit script-src, or otherwise to the default sources.

If 'unsafe-inline' is not in the list of allowed script sources, or if at least one nonce-source or hash-source is present in the list of allowed script sources:

Whenever the user agent would execute an inline script from a script element that lacks a valid nonce and lacks a valid hash for the allowed script sources, instead the user agent MUST NOT execute script, and MUST report a violation.
Whenever the user agent would execute an inline script from an inline event handler, instead the user agent MUST NOT execute script, and MUST report a violation.
Whenever the user agent would execute script contained in a javascript URL, instead the user agent MUST NOT execute the script, and MUST report a violation.

If 'unsafe-eval' is not in allowed script sources:

Instead of evaluating their arguments, both operator eval and function eval [ECMA-262] MUST throw an EvalError exception.
When called as a constructor, the function Function [ECMA-262] MUST throw an EvalError exception.
When called with a first argument that is not callable (a string, for example), the setTimeout() function MUST return zero without creating a timer.
When called with a first argument that is not callable (a string, for example), the setInterval() function MUST return zero without creating a timer.

Whenever the user agent fetches a URL (including when following redirects) in the course of one of the following activities, if the URL does not match the allowed script sources for the protected resource, the user agent MUST act as if there was a fatal network error and no resource was obtained, and report a violation:

Requesting a script while processing the src attribute of a script element that lacks a valid nonce for the allowed script sources.
Requesting a script while invoking the importScripts method on a WorkerGlobalScope object. [WORKERS]
Requesting an HTML component, such as when processing the href attribute of a link element with a rel attribute containing the token import. [HTML-IMPORTS]
Requesting an Extensible Stylesheet Language Transformations (XSLT) [XSLT], such as when processing the <?xml-stylesheet?> processing directive in an XML document [XML11], the href attributes on <xsl:include> and <xsl:import> elements.

7.15.1. Nonce usage for `script` elements

This section is not normative.

The script-src directive lets developers specify exactly which script elements on a page were intentionally included for execution. Ideally, developers would avoid inline script entirely and whitelist scripts by URL. However, in some cases, removing inline scripts can be difficult or impossible. For those cases, developers can whitelist scripts using a randomly generated nonce.

Usage is straightforward. For each request, the server generates a unique value at random, and includes it in the Content-Security-Policy header:

Content-Security-Policy: default-src 'self';
                         script-src 'self' https://example.com 'nonce-$RANDOM'

This same value is then applied as a nonce attribute to each script element that ought to be executed. For example, if the server generated the random value Nc3n83cnSAd3wc3Sasdfn939hc3, the server would send the following policy:

Content-Security-Policy: default-src 'self';
                         script-src 'self' https://example.com 'nonce-Nc3n83cnSAd3wc3Sasdfn939hc3'

Script elements can then execute either because their src URLs are whitelisted or because they have a valid nonce:

<script>
alert("Blocked because the policy doesn’t have 'unsafe-inline'.")
</script>

<script nonce="EDNnf03nceIOfn39fn3e9h3sdfa">
alert("Still blocked because nonce is wrong.")
</script>

<script nonce="Nc3n83cnSAd3wc3Sasdfn939hc3">
alert("Allowed because nonce is valid.")
</script>

<script src="https://example.com/allowed-because-of-src.js"></script>

<script nonce="EDNnf03nceIOfn39fn3e9h3sdfa"
    src="https://elsewhere.com/blocked-because-nonce-is-wrong.js"></script>

<script nonce="Nc3n83cnSAd3wc3Sasdfn939hc3"
    src="https://elsewhere.com/allowed-because-nonce-is-valid.js"></script>

Note that the nonce’s value is not a hash or signature that verifies the contents of the script resources. It’s quite simply a random string that informs the user agent which scripts were intentionally included in the page.

Script elements with the proper nonce execute, regardless of whether they’re inline or external. Script elements without the proper nonce don’t execute unless their URLs are whitelisted. Even if an attacker is able to inject markup into the protected resource, the attack will be blocked by the attacker’s inability to guess the random value.

7.15.2. Hash usage for `script` elements

This section is not normative.

The script-src directive lets developers whitelist a particular inline script by specifying its hash as an allowed source of script.

Usage is straightforward. The server computes the hash of a particular script block’s contents, and includes the base64 encoding of that value in the Content-Security-Policy header:

Content-Security-Policy: default-src 'self';
                         script-src 'self' https://example.com 'sha256-base64 encoded hash'

Each inline script block’s contents are hashed, and compared against the whitelisted value. If there’s a match, the script is executed. For example, the SHA-256 digest of alert('Hello, world.'); is qznLcsROx4GACP2dm0UCKCzCG+HiZ1guq6ZZDob/Tng=.

You can obtain the digest of a string on the command line simply via the openssl program. For example:

echo -n "alert('Hello, world.');" | openssl dgst -sha256 -binary | openssl enc -base64

If the server sent the following header:

Content-Security-Policy: script-src 'sha512-YWIzOWNiNzJjNDRlYzc4MTgwMDhmZDlkOWI0NTAyMjgyY2MyMWJlMWUyNjc1ODJlYWJhNjU5MGU4NmZmNGU3OAo='

Then the following script tag would result in script execution:

<script>alert('Hello, world.');</script>

Whitespace is significant. The following scripts blocks would not hash to the same value, and would therefore not execute:

<script> alert('Hello, world.');</script>
<script>alert('Hello, world.'); </script>
<script> alert('Hello, world.'); </script>
<script>
alert('Hello, world.');
</script>

Note also that the hash applies only to inline script. An externalized script containing the value alert('Hello, world.'); would not execute if its origin was not whitelisted as a valid source of script.

7.16. `style-src`

The style-src directive restricts which styles the user may applies to the protected resource. The syntax for the name and value of the directive are described by the following ABNF grammar:

directive-name    = "style-src"
directive-value   = source-list

The term allowed style sources refers to the result of parsing the style-src directive’s value as a source list if the policy contains an explicit style-src, or otherwise to the default sources.

If 'unsafe-inline' is not in the list of allowed style sources, or if at least one nonce-source or hash-source is present in the list of allowed style sources:

Whenever the user agent would apply style from a style element that lacks a valid nonce and lacks a valid hash for the allowed style sources, instead the user agent MUST ignore the style, and MUST report a violation.
Whenever the user agent would apply style from a style attribute, instead the user agent MUST ignore the style, and MUST report a violation.

Note: These restrictions on inline do not prevent the user agent from applying style from an external stylesheet (e.g., found via <link rel="stylesheet" ...>).

If 'unsafe-eval' is not in allowed style sources, then:

Whenever the user agent would invoke the Cascading Style Sheets Object Model algorithms insert a CSS rule, parse a CSS rule, parse a CSS declaration block, or parse a group of selectors instead the user agent MUST throw a SecurityError exception and terminate the algorithm. This would include, for example, all invocations of CSSOM’s various cssText setters and insertRule methods. [CSSOM] [HTML5]

Whenever the user agent fetches a URL in the course of one of the following activities, if the URL does not match the allowed style sources for the protected resource, the user agent MUST act as if there was a fatal network error and no resource was obtained, and report a violation:

Requesting an external stylesheet when processing the href of a link element whose rel attribute contains the token stylesheet.
Requesting an external stylesheet when processing the <@import> directive.
Requesting an external stylesheet when processing a Link HTTP response header field [RFC5988].
Note: As this stylesheet might be prefetched before a Document actually exists, user agents will need to carefully consider how to instantiate a meaningful policy against which to compare this request. See §10.1 Processing Complications for more detail.

Note: The style-src directive does not restrict the use of XSLT. XSLT is restricted by the script-src directive because the security consequences of including an untrusted XSLT stylesheet are similar to those incurred by including an untrusted script.

7.16.1. Nonce usage for `style` elements

This section is not normative.

See the script-src nonce usage information for detail; the application of nonces to style elements is similar enough to avoid repetition here.

7.16.2. Hash usage for `style` elements

This section is not normative.

See the script-src hash usage information for detail; the application of hashes to style elements is similar enough to avoid repetition here.

8. Examples

8.1. Sample Policy Definitions

This section provides some sample use cases and supporting policies.

A server wishes to load resources only from its own origin:

Content-Security-Policy: default-src 'self'

An auction site wishes to load images from any URL, plugin content from a list of trusted media providers (including a content distribution network), and scripts only from a server under its control hosting sanitized ECMAScript:

Content-Security-Policy:
    default-src 'self'; img-src *;
    object-src media1.example.com media2.example.com *.cdn.example.com;
    script-src trustedscripts.example.com

An online banking site wishes to ensure that all of the content in its pages is loaded over TLS to prevent attackers from eavesdropping on insecure content requests:

Content-Security-Policy: default-src https: 'unsafe-inline' 'unsafe-eval'

This policy allows inline content (such as inline script elements), use of eval, and loading resources over https. Note: This policy does not provide any protection from cross-site scripting vulnerabilities.

A website that relies on inline script elements wishes to ensure that script is only executed from its own origin, and those elements it intentionally inserted inline:

Content-Security-Policy: script-src 'self' 'nonce-$RANDOM';

The inline script elements would then only execute if they contained a matching nonce attribute:

<script nonce="$RANDOM">...</script>

8.2. Sample Violation Report

This section contains an example violation report the user agent might sent to a server when the protected resource violations a sample policy.

In the following example, the user agent rendered a representation of the resource http://example.org/page.html with the following policy:

default-src 'self'; report-uri http://example.org/csp-report.cgi

The protected resource loaded an image from http://evil.example.com/image.png, violating the policy.

{
  "csp-report": {
    "document-uri": "http://example.org/page.html",
    "referrer": "http://evil.example.com/haxor.html",
    "blocked-uri": "http://evil.example.com/image.png",
    "violated-directive": "default-src 'self'",
    "effective-directive": "img-src",
    "original-policy": "default-src 'self'; report-uri http://example.org/csp-report.cgi"
  }
}

9. Security Considerations

9.1. Cascading Style Sheet (CSS) Parsing

The style-src directive restricts the locations from which the protected resource can load styles. However, if the user agent uses a lax CSS parsing algorithm, an attacker might be able to trick the user agent into accepting malicious "stylesheets" hosted by an otherwise trustworthy origin.

These attacks are similar to the CSS cross-origin data leakage attack described by Chris Evans in 2009. User agents SHOULD defend against both attacks using the same mechanism: stricter CSS parsing rules for style sheets with improper MIME types.

9.2. Violation Reports

The violation reporting mechanism in this document has been designed to mitigate the risk that a malicious web site could use violation reports to probe the behavior of other servers. For example, consider a malicious web site that white lists https://example.com as a source of images. If the malicious site attempts to load https://example.com/login as an image, and the example.com server redirects to an identity provider (e.g., identityprovider.example.net), CSP will block the request. If violation reports contained the full blocked URL, the violation report might contain sensitive information contained in the redirected URL, such as session identifiers or purported identities. For this reason, the user agent includes only the origin of the blocked URL.

10. Implementation Considerations

The Content-Security-Policy header is an end-to-end header. It is processed and enforced at the client and, therefore, SHOULD NOT be modified or removed by proxies or other intermediaries not in the same administrative domain as the resource.

The originating administrative domain for a resource might wish to apply a Content-Security-Policy header outside of the immediate context of an application. For example, a large organization might have many resources and applications managed by different individuals or teams but all subject to a uniform organizational standard. In such situations, a Content-Security-Policy header might be added or combined with an existing one at a network-edge security gateway device or web application firewall. To enforce multiple policies, the administrator SHOULD combine the policy into a single header. An administrator might wish to use different combination algorithms depending on his or her intended semantics.

One sensible policy combination algorithm is to start by allowing a default set of sources and then letting individual upstream resource owners expand the set of allowed sources by including additional origins. In this approach, the resultant policy is the union of all allowed origins in the input policies.

Another sensible policy combination algorithm is to intersect the given policies. This approach enforces that content comes from a certain whitelist of origins, for example, preventing developers from including third-party scripts or content in violation of organizational standards and practices. In this approach, the combination algorithm forms the combined policy by removing disallowed hosts from the policies supplied by upstream resource owners.

Interactions between the default-src and other directives SHOULD be given special consideration when combining policies. If none of the policies contains a default-src directive, adding new src directives results in a more restrictive policy. However, if one or more of the input policies contain a default-src directive, adding new src directives might result in a less restrictive policy, for example, if the more specific directive contains a more permissive set of allowed origins.

Using a more restrictive policy than the input policy authored by the resource owner might prevent the resource from rendering or operating as intended.

Note: Migration to HTTPS from HTTP may require updates to the policy in order to keep things running as before. Source expressions like http://example.com do not match HTTPS resources. For example, administrators SHOULD carefully examine existing policies before rolling out HTTP Strict Transport Security headers for an application. [RFC6797]

Server administrators MAY wish to send multiple policies if different reporting options are desired for subsets of an overall policy. For instance, the following headers:

Content-Security-Policy: frame-ancestors https://example.com/ 
Content-Security-Policy: default-src https:; report-uri https://example.com/

would send violation reports for http resources, but would not send violation reports for frame-ancestors violations. Note also that combining them via ',' into the single header

Content-Security-Policy: frame-ancestors https://example.com/, default-src https:; report-uri https://example.com/

would have the same effect, as the comma splits the header during parsing.

10.1. Processing Complications

Many user agents implement some form of optimistic resource fetching algorithm to speed up page loads. In implementing these features, user agents MUST ensure that these optimizations do not alter the behavior of the page’s security policy.

Here, we’ll note a few potential complications that could cause bugs in implementations:

The frame-ancestor directive MUST take effect before a document is loaded into a nested browsing context, and certainly before script is potentially executed. One way to approach this constraint is to perform the ancestor check defined in §7.7 frame-ancestors while parsing the document’s headers. This might mean that no document object is available at all, which can complicate checks against 'self', and scheme- or port-relative source expressions.
Likewise, the Link HTTP response header could generate requests for stylesheet resources before a document is available. User agents MUST ensure that any policy contained in the response headers is parsed and effective before these requests are generated. For example, a response returning the following headers:
```
Content-Security-Policy: style-src 'none'
Link: <awesome.css>; rel=stylesheet
```
MUST have the same behavior as a response returning the following headers:
```
Link: <awesome.css>; rel=stylesheet
Content-Security-Policy: style-src 'none'
```
namely, both must block requests for the stylesheet. To fulfil this requirement user agents MUST wait until all headers have been processed before beginning to prefetch resources.

11. IANA Considerations

The permanent message header field registry should be updated with the following registrations: [RFC3864]

11.1. Content-Security-Policy

Header field name: Content-Security-Policy
Applicable protocol: http
Status: standard
Author/Change controller: W3C
Specification document: This specification (See Content-Security-Policy Header Field)

11.2. Content-Security-Policy-Report-Only

Header field name: Content-Security-Policy-Report-Only
Applicable protocol: http
Status: standard
Author/Change controller: W3C
Specification document: This specification (See Content-Security-Policy-Report-Only Header Field)

11.3. CSP

Header field name: CSP
Applicable protocol: http
Status: standard
Author/Change controller: W3C
Specification document: This specification (See §3.4 The CSP HTTP Request Header)

12. Acknowledgements

In addition to the documents in the W3C Web Application Security working group, the work on this document is also informed by the work of the IETF websec working group, particularly that working group’s requirements document: draft-hodges-websec-framework-reqs.

A portion of the frame-ancestors directive was originally developed as X-Frame-Options. [RFC7034]

Brian Smith, Neil Matatall, Anne van Kesteren, and Sigbjørn Vik provided particularly insightful feedback to keep this specification sane.

1. Introduction

This section is not normative.

This document defines Content Security Policy (CSP), a tool which developers can use to lock down their applications in various ways, mitigating the risk of content injection vulnerabilities such as cross-site scripting, and reducing the privilege with which their applications execute.

CSP is not intended as a first line of defense against content injection vulnerabilities. Instead, CSP is best used as defense-in-depth. It reduces the harm that a malicious injection can cause, but it is not a replacement for careful input validation and output encoding.

This document is an iteration on Content Security Policy Level 2, with the goal of more clearly explaining the interactions between CSP, HTML, and Fetch on the one hand, and providing clear hooks for modular extensibility on the other. Ideally, this will form a stable core upon which we can build new functionality.

1.1. Examples

1.1.1. Control Execution

MegaCorp Inc’s developers want to protect themselves against cross-site scripting attacks. They can mitigate the risk of script injection by ensuring that their trusted CDN is the only origin from which script can load and execute. Moreover, they wish to ensure that no plugins can execute in their pages' contexts. The following policy has that effect:

Content-Security-Policy: script-src https://cdn.example.com/scripts/; object-src 'none'

1.2. Goals

Content Security Policy aims to do to a few related things:

Mitigate the risk of content-injection attacks by giving developers fairly granular control over
- The resources which can be requested (and subsequently embedded or executed) on behalf of a specific Document or Worker
- The execution of inline script
- Dynamic code execution (via eval() and similar constructs)
- The application of inline style
Mitigate the risk of attacks which require a resource to be embedded in a malicious context (the "Pixel Perfect" attack described in [TIMING], for example) by giving developers granular control over the origins which can embed a given resource.
Provide a policy framework which allows developers to reduce the privilege of their applications.
Provide a reporting mechanism which allows developers to detect flaws being exploited in the wild.

1.3. Changes from Level 2

This document describes an evolution of the Content Security Policy Level 2 specification [CSP2]. The following is a high-level overview of the changes:

The specification has been rewritten from the ground up in terms of the [FETCH] specification, which should make it simpler to integrate CSP’s requirements and restrictions with other specifications (and with Service Workers in particular).
The child-src model has been substantially altered:
1. The frame-src directive, which was deprecated in CSP Level 2, has been undeprecated, but continues to defer to child-src if not present (which defers to default-src in turn).
2. A worker-src directive has been added, deferring to script-src if not present (which likewise defers to default-src in turn).
3. child-src is now deprecated.
4. Dedicated workers now always inherit their creator’s policy.
The URL matching algorithm now treats insecure schemes and ports as matching their secure variants. That is, the source expression http://example.com:80 will match both http://example.com:80 and https://example.com:443.

Likewise, 'self' now matches https: and wss: variants of the page’s origin, even on pages whose scheme is http.
Violation reports generated from inline script or style will now report "inline" as the blocked resource. Likewise, blocked eval() execution will report "eval" as the blocked resource.
The manifest-src directive has been added.
The report-uri directive is deprecated in favor of the new report-to directive, which relies on [REPORTING] as infrastructure.
The 'strict-dynamic' source expression will now allow script which executes on a page to load more script via non-"parser-inserted" script elements. Details are in §8.2 Usage of "'strict-dynamic'".
The 'unsafe-hashed-attributes' source expression will now allow event handlers and style attributes to match hash source expressions. Details in §8.3 Usage of "'unsafe-hashed-attributes'".
unsafe-hashed-attributes is a work in progress. <https://github.com/w3c/webappsec-csp/issues/13>
The source expression matching has been changed to require explicit presence of any non-network scheme, rather than local scheme, unless that non-network scheme is the same as the scheme of protected resource, as described in §6.6.1.6 Does url match expression in origin with redirect count?.
Hash-based source expressions may now match external scripts if the script element that triggers the request specifies a set of integrity metadata which is listed in the current policy. Details in §8.4 Allowing external JavaScript via hashes.
The disown-opener directive ensures that a resource can’t be opened in such a way as to give another browsing context control over its contents.
disown-opener is a work in progress. <https://github.com/w3c/webappsec-csp/issues/194>
The navigation-to directive gives a resource control over the endpoints to which it can initiate navigation.
navigation-to is a work in progress. <https://github.com/w3c/webappsec-csp/issues/125>
Reports generated for inline violations will contain a sample attribute if the relevant directive contains the 'report-sample' expression.

2. Framework

2.1. Infrastructure

This document uses ABNF grammar to specify syntax, as defined in [RFC5234]. It also relies on the #rule ABNF extension defined in Section 7 of [RFC7230].

This document depends on the Infra Standard for a number of foundational concepts used in its algorithms and prose [INFRA].

2.2. Policies

A policy defines allowed and restricted behaviors, and may be applied to a Window, WorkerGlobalScope, or WorkletGlobalScope as described in §4.2.2 Initialize a global object’s CSP list.

Each policy has an associated directive set, which is an ordered set of directives that define the policy’s implications when applied.

Each policy has an associated disposition, which is either "enforce" or "report".

Each policy has an associated source, which is either "header" or "meta".

Multiple policies can be applied to a single resource, and are collected into a list of policies known as a CSP list.

A CSP list contains a header-delivered Content Security Policy if it contains a policy whose source is "header".

A serialized CSP is an ASCII string consisting of a semicolon-delimited series of serialized directives, adhering to the following ABNF grammar [RFC5234]:

serialized-policy = serialized-directive *( OWS ";" [ OWS serialized-directive ] )
                    ; OWS is defined in section 3.2.3 of RFC 7230

A serialized CSP list is an ASCII string consisting of a comma-delimited series of serialized CSPs, adhering to the following ABNF grammar [RFC5234]:

serialized-policy-list = 1#serialized-policy
                    ; The '#' rule is defined in section 7 of RFC 7230

2.2.1. Parse a serialized CSP

To parse a serialized CSP, given a serialized CSP (serialized), a source (source), and a disposition (disposition), execute the following steps.

This algorithm returns a Content Security Policy object. If serialized could not be parsed, the object’s directive set will be empty.

Let policy be a new policy with an empty directive set, a source of source, and a disposition of disposition.
For each token returned by strictly splitting serialized on the U+003B SEMICOLON character (;):
1. Strip leading and trailing ASCII whitespace from token.
2. If token is an empty string, continue.
3. Let directive name be the result of collecting a sequence of code points from token which are not ASCII whitespace.
4. If policy’s directive set contains a directive whose name is directive name, continue.
  
  In this case, the user agent SHOULD notify developers that a duplicate directive was ignored. A console warning might be appropriate, for example.
5. Let directive value be the result of splitting token on ASCII whitespace.
6. Let directive be a new directive whose name is directive name, and value is directive value.
7. Append directive to policy’s directive set.
Return policy.

2.2.2. Parse a serialized CSP list

To parse a serialized CSP list, given a serialized CSP list (list), a source (source), and a disposition (disposition), execute the following steps.

This algorithm returns a list of Content Security Policy objects. If list cannot be parsed, the returned list will be empty.

Let policies be an empty list.
For each token returned by splitting list on commas:
1. Let policy be the result of parsing token, with a source of source, and disposition of disposition.
2. If policy’s directive set is empty, continue.
3. Append policy to policies.
Return policies.

2.3. Directives

Each policy contains an ordered set of directives (its directive set), each of which controls a specific behavior. The directives defined in this document are described in detail in §6 Content Security Policy Directives.

Each directive is a name / value pair. The name is a non-empty string, and the value is a set of non-empty strings. The value MAY be empty.

A serialized directive is an ASCII string, consisting of one or more whitespace-delimited tokens, and adhering to the following ABNF [RFC5234]:

serialized-directive = directive-name [ RWS directive-value ]
directive-name       = 1*( ALPHA / DIGIT / "-" )
directive-value      = *( %x09 / %x20-%x2B / %x2D-%x3A / %x3C-%7E )
                       ; Directive values may contain whitespace and VCHAR characters,
                       ; excluding ";" and ","

; RWS is defined in section 3.2.3 of RFC7230. ALPHA, DIGIT, and
; VCHAR are defined in Appendix B.1 of RFC 5234.

Directives have a number of associated algorithms:

A pre-request check, which takes a request and a policy as an argument, and is executed during §4.1.3 Should request be blocked by Content Security Policy?. This algorithm returns "Allowed" unless otherwise specified.
A post-request check, which takes a request, a response, and a policy as arguments, and is executed during §4.1.4 Should response to request be blocked by Content Security Policy?. This algorithm returns "Allowed" unless otherwise specified.
A response check, which takes a request, a response, and a policy as arguments, and is executed during §4.1.4 Should response to request be blocked by Content Security Policy?. This algorithm returns "Allowed" unless otherwise specified.
An inline check, which takes an Element a type string, and a soure string as arguments, and is executed during §4.2.4 Should element’s inline type behavior be blocked by Content Security Policy?. This algorithm returns "Allowed" unless otherwise specified.
An initialization, which takes a Document or global object, a response, and a policy as arguments. This algorithm is executed during §4.2.1 Initialize a Document's CSP list, and has no effect unless otherwise specified.
A pre-navigation check, which takes a request, type string, and two browsing contexts as arguments, and is executed during §4.2.5 Should navigation request of type from source in target be blocked by Content Security Policy?. It returns "Allowed" unless otherwise specified.
A navigation response check, which takes a request, a response and two browsing contexts as arguments, and is executed during §4.2.6 Should navigation response to navigation request of type from source in target be blocked by Content Security Policy?. It returns "Allowed" unless otherwise specified.

2.3.1. Source Lists

Many directives' values consist of source lists: sets of strings which identify content that can be fetched and potentially embedded or executed. Each string represents one of the following types of source expression:

Keywords such as 'none' and 'self' (which match nothing and the current URL’s origin, respectively)
Serialized URLs such as https://example.com/path/to/file.js (which matches a specific file) or https://example.com/ (which matches everything on that origin)
Schemes such as https: (which matches any resource having the specified scheme)
Hosts such as example.com (which matches any resource on the host, regardless of scheme) or *.example.com (which matches any resource on the host’s subdomains (and any of its subdomains' subdomains, and so on))
Nonces such as 'nonce-ch4hvvbHDpv7xCSvXCs3BrNggHdTzxUA' (which can match specific elements on a page)
Digests such as 'sha256-abcd...' (which can match specific elements on a page)

A serialized source list is an ASCII string, consisting of a whitespace-delimited series of source expressions, adhering to the following ABNF grammar [RFC5234]:

serialized-source-list = ( source-expression *( RWS source-expression ) ) / "'none'"
source-expression      = scheme-source / host-source / keyword-source
                         / nonce-source / hash-source

; Schemes: "https:" / "custom-scheme:" / "another.custom-scheme:"
scheme-source = scheme-part ":"

; Hosts: "example.com" / "*.example.com" / "https://*.example.com:12/path/to/file.js"
host-source = [ scheme-part "://" ] host-part [ ":" port-part ] [ path-part ]
scheme-part = scheme
              ; scheme is defined in section 3.1 of RFC 3986.
host-part   = "*" / [ "*." ] 1*host-char *( "." 1*host-char )
host-char   = ALPHA / DIGIT / "-"
port-part   = 1*DIGIT / "*"
path-part   = path-absolute
              ; path-absolute is defined in section 3.3 of RFC 3986.

; Keywords:
keyword-source = "'self'" / "'unsafe-inline'" / "'unsafe-eval'"
                 / "'strict-dynamic'" / "'unsafe-hashed-attributes'" /
                 / "'report-sample'"

; Nonces: 'nonce-[nonce goes here]'
nonce-source  = "'nonce-" base64-value "'"
base64-value  = 1*( ALPHA / DIGIT / "+" / "/" / "-" / "_" )*2( "=" )

; Digests: 'sha256-[digest goes here]'
hash-source    = "'" hash-algorithm "-" base64-value "'"
hash-algorithm = "sha256" / "sha384" / "sha512"

The host-char production intentionally contains only ASCII characters; internationalized domain names cannot be entered directly as part of a serialized CSP, but instead MUST be Punycode-encoded [RFC3492]. For example, the domain üüüüüü.de MUST be represented as xn--tdaaaaaa.de.

Note: Though IP address do match the grammar above, only 127.0.0.1 will actually match a URL when used in a source expression (see §6.6.1.5 Does url match source list in origin with redirect count? for details). The security properties of IP addresses are suspect, and authors ought to prefer hostnames whenever possible.

Note: The base64-value grammar allows both base64 and base64url encoding. These encodings are treated as equivalant when processing hash-source values. Nonces, however, are strict string matches: we use the base64-value grammar to limit the characters available, and reduce the complexity for the server-side operator (encodings, etc), but the user agent doesn’t actually care about any underlying value, nor does it do any decoding of the nonce-source value.

2.4. Violations

A violation represents an action or resource which goes against the set of policy objects associated with a global object.

Each violation has a global object, which is the global object whose policy has been violated.

Each violation has a url which is its global object’s URL.

Each violation has a status which is a non-negative integer representing the HTTP status code of the resource for which the global object was instantiated.

Each violation has a resource, which is either null, "inline", "eval", or a URL. It represents the resource which violated the policy.

Each violation has a referrer, which is either null, or a URL. It represents the referrer of the resource whose policy was violated.

Each violation has a policy, which is the policy that has been violated.

Each violation has a disposition, which is the disposition of the policy that has been violated.

Each violation has an effective directive which is a non-empty string representing the directive whose enforcement caused the violation.

Each violation has a source file, which is either null or a URL.

Each violation has a line number, which is a non-negative integer.

Each violation has a column number, which is a non-negative integer.

Each violation has a element, which is either null or an element.

Each violation has a sample, which is a string. It is the empty string unless otherwise specified.

Note: A violation’s sample will be populated with the first 40 characters of an inline script, event handler, or style that caused an violation. Violations which stem from an external file will not include a sample in the violation report.

2.4.1. Create a violation object for `global`, `policy`, and `directive`

Given a global object (global), a policy (policy), and a string (directive), the following algorithm creates a new violation object, and populates it with an initial set of data:

Let violation be a new violation whose global object is global, policy is policy, effective directive is directive, and resource is null.
If the user agent is currently executing script, and can extract a source file’s URL, line number, and column number from the global, set violation’s source file, line number, and column number accordingly.

Is this kind of thing specified anywhere? I didn’t see anything that looked useful in [ECMA262].

Note: User agents need to ensure that the source file is the URL requested by the page, pre-redirects. If that’s not possible, user agents need to strip the URL down to an origin to avoid unintentional leakage.
If global is a Window object, set violation’s referrer to global’s document's referrer.
Set violation’s status to the HTTP status code for the resource associated with violation’s global object.

How, exactly, do we get the status code? We don’t actually store it anywhere.
Return violation.

2.4.2. Create a violation object for `request`, `policy`, and `directive`

Given a request (request), a policy (policy), and a string (directive), the following algorithm creates a new violation object, and populates it with an initial set of data:

Let violation be the result of executing §2.4.1 Create a violation object for global, policy, and directive on request’s client’s global object, policy, and directive.
Set violation’s resource to request’s url.

Note: We use request’s url, and not its current url, as the latter might contain information about redirect targets to which the page MUST NOT be given access.
Return violation.

3. Policy Delivery

A server MAY declare a policy for a particular resource representation via an HTTP response header field whose value is a serialized CSP. This mechanism is defined in detail in §3.1 The Content-Security-Policy HTTP Response Header Field and §3.2 The Content-Security-Policy-Report-Only HTTP Response Header Field, and the integration with Fetch and HTML is described in §4.1 Integration with Fetch and §4.2 Integration with HTML.

A policy may also be declared inline in an HTML document via a meta element’s http-equiv attribute, as described in §3.3 The <meta> element.

3.1. The `Content-Security-Policy` HTTP Response Header Field

The Content-Security-Policy HTTP response header field is the preferred mechanism for delivering a policy from a server to a client. The header’s value is represented by the following ABNF [RFC5234]:

Content-Security-Policy = 1#serialized-policy

Content-Security-Policy: script-src 'self';
                         report-to csp-reporting-endpoint

A server MAY send different Content-Security-Policy header field values with different representations of the same resource.

A server SHOULD NOT send more than one HTTP response header field named "Content-Security-Policy" with a given resource representation.

When the user agent receives a Content-Security-Policy header field, it MUST parse and enforce each serialized CSP it contains as described in §4.1 Integration with Fetch, §4.2 Integration with HTML.

3.2. The `Content-Security-Policy-Report-Only` HTTP Response Header Field

The Content-Security-Policy-Report-Only HTTP response header field allows web developers to experiment with policies by monitoring (but not enforcing) their effects. The header’s value is represented by the following ABNF [RFC5234]:

Content-Security-Policy-Report-Only = 1#serialized-policy

This header field allows developers to piece together their security policy in an iterative fashion, deploying a report-only policy based on their best estimate of how their site behaves, watching for violation reports, and then moving to an enforced policy once they’ve gained confidence in that behavior.

Content-Security-Policy-Report-Only: script-src 'self';
                                     report-to csp-reporting-endpoint

A server MAY send different Content-Security-Policy-Report-Only header field values with different representations of the same resource.

A server SHOULD NOT send more than one HTTP response header field named "Content-Security-Policy-Report-Only" with a given resource representation.

When the user agent receives a Content-Security-Policy-Report-Only header field, it MUST parse and monitor each serialized CSP it contains as described in §4.1 Integration with Fetch and §4.2 Integration with HTML.

Note: The Content-Security-Policy-Report-Only header is not supported inside a meta element.

3.3. The `<meta>` element

A Document may deliver a policy via one or more HTML meta elements whose http-equiv attributes are an ASCII case-insensitive match for the string "Content-Security-Policy". For example:

<meta http-equiv="Content-Security-Policy" content="script-src 'self'">

Implementation details can be found in HTML’s Content Security Policy state http-equiv processing instructions [HTML].

Note: The Content-Security-Policy-Report-Only header is not supported inside a meta element. Neither are the report-uri, frame-ancestors, and sandbox directives.

Authors are strongly encouraged to place meta elements as early in the document as possible, because policies in meta elements are not applied to content which precedes them. In particular, note that resources fetched or prefetched using the Link HTTP response header field, and resources fetched or prefetched using link and script elements which precede a meta-delivered policy will not be blocked.

Note: Modifications to the content attribute of a meta element after the element has been parsed will be ignored.

4. Integrations

This section is non-normative.

This document defines a set of algorithms which are used in other specifications in order to implement the functionality. These integrations are outlined here for clarity, but those external documents are the normative references which ought to be consulted for detailed information.

4.1. Integration with Fetch

A number of directives control resource loading in one way or another. This specification provides algorithms which allow Fetch to make decisions about whether or not a particular request should be blocked or allowed, and about whether a particular response should be replaced with a network error.

§4.1.3 Should request be blocked by Content Security Policy? is called as part of step #5 of its Main Fetch algorithm. This allows directives' pre-request checks to be executed against each request before it hits the network, and against each redirect that a request might go through on its way to reaching a resource.
§4.1.4 Should response to request be blocked by Content Security Policy? is called as part of step #13 of its Main Fetch algorithm. This allows directives' post-request checks and response checks to be executed on the response delivered from the network or from a Service Worker.

A policy is generally enforced upon a global object, but the user agent needs to parse any policy delivered via an HTTP response header field before any global object is created in order to handle directives that require knowledge of a response’s details. To that end:

A response has an associated CSP list which contains any policy objects delivered in the response’s header list.
§4.1.1 Set response’s CSP list is called in the HTTP fetch and HTTP-network fetch algorithms.

Note: These two calls should ensure that a response’s CSP list is set, regardless of how the response is created. If we hit the network (via HTTP-network fetch, then we parse the policy before we handle the Set-Cookie header. If we get a response from a Service Worker (via HTTP fetch, we’ll process its CSP list before handing the response back to our caller.

4.1.1. Set `response`’s `CSP list`

Given a response (response), this algorithm evaluates its header list for serialized CSP values, and populates its CSP list accordingly:

Set response’s CSP list to the empty list.
Let policies be the result of parsing the result of extracting header list values given Content-Security-Policy and response’s header list, with a source of "header", and a disposition of "enforce".
Append to policies the result of parsing the result of extracting header list values given Content-Security-Policy-Report-Only and response’s header list, with a source of "header", and a disposition of "report".
For each policy in policies:
1. Insert policy into response’s CSP list.

4.1.2. Report Content Security Policy violations for `request`

Given a request (request), this algorithm reports violations based on client’s "report only" policies.

Let CSP list be request’s client’s global object’s CSP list.
For each policy in CSP list:
1. If policy’s disposition is "enforce", then skip to the next policy.
2. Let violates be the result of executing §6.6.1.1 Does request violate policy? on request and policy.
3. If violates is not "Does Not Violate", then execute §5.3 Report a violation on the result of executing §2.4.2 Create a violation object for request, policy, and directive on request, policy, and violates.

4.1.3. Should `request` be blocked by Content Security Policy?

Given a request (request), this algorithm returns Blocked or Allowed and reports violations based on request’s client’s Content Security Policy.

Let CSP list be request’s client’s global object’s CSP list.
Let result be "Allowed".
For each policy in CSP list:
1. If policy’s disposition is "report", then skip to the next policy.
2. Let violates be the result of executing §6.6.1.1 Does request violate policy? on request and policy.
3. If violates is not "Does Not Violate", then:
  1. Execute §5.3 Report a violation on the result of executing §2.4.2 Create a violation object for request, policy, and directive on request, policy, and violates.
  2. Set result to "Blocked".
Return result.

4.1.4. Should `response` to `request` be blocked by Content Security Policy?

Given a response (response) and a request (request), this algorithm returns Blocked or Allowed, and reports violations based on request’s client’s Content Security Policy.

Let CSP list be request’s client’s global object’s CSP list.
Let result be "Allowed".
For each policy in CSP list:
1. For each directive in policy:
  1. If the result of executing directive’s post-request check is "Blocked", then:
    1. Execute §5.3 Report a violation on the result of executing §2.4.2 Create a violation object for request, policy, and directive on request, policy, and directive.
    2. If policy’s disposition is "enforce", then set result to "Blocked".
Note: This portion of the check verifies that the page can load the response. That is, that a Service Worker hasn’t substituted a file which would violate the page’s CSP.
For each policy in response’s CSP list:
1. For each directive in policy:
  1. If the result of executing directive’s response check on request, response, and policy is "Blocked", then:
    1. Execute §5.3 Report a violation on the result of executing §2.4.2 Create a violation object for request, policy, and directive on request, policy, and directive.
    2. If policy’s disposition is "enforce", then set result to "Blocked".
Note: This portion of the check allows policies delivered with the response to determine whether the response is allowed to be delivered.
Return result.

4.2. Integration with HTML

The Document, WorkerGlobalScope, and WorkletGlobalScope objects have a CSP list, which holds all the policy objects which are active for a given context. This list is empty unless otherwise specified, and is populated via the §4.2.2 Initialize a global object’s CSP list algorithm.

This concept is missing from W3C’s Workers. <https://github.com/w3c/html/issues/187>
A global object’s CSP list is the result of executing §4.2.3 Retrieve the CSP list of an object with the global object as the object.
A policy is enforced or monitored for a global object by inserting it into the global object’s CSP list.
§4.2.2 Initialize a global object’s CSP list is called during the initializing a new Document object and run a worker algorithms in order to bind a set of policy objects associated with a response to a newly created Document, WorkerGlobalScope or WorkletGlobalScope.
§4.2.4 Should element’s inline type behavior be blocked by Content Security Policy? is called during the prepare a script and update a style block algorithms in order to determine whether or not an inline script or style block is allowed to execute/render.
§4.2.4 Should element’s inline type behavior be blocked by Content Security Policy? is called during handling of inline event handlers (like onclick) and inline style attributes in order to determine whether or not they ought to be allowed to execute/render.
policy is enforced during processing of the meta element’s http-equiv.
A Document's embedding document is the Document through which the Document's browsing context is nested.
HTML populates each request’s cryptographic nonce metadata and parser metadata with relevant data from the elements responsible for resource loading.

Stylesheet loading is not yet integrated with Fetch in W3C’s HTML. <https://github.com/whatwg/html/issues/198>

Stylesheet loading is not yet integrated with Fetch in WHATWG’s HTML. <https://github.com/whatwg/html/issues/968>
§6.2.1.1 Is base allowed for document? is called during base's set the frozen base URL algorithm to ensure that the href attribute’s value is valid.
§6.2.2.2 Should plugin element be blocked a priori by Content Security Policy?: is called during the processing of object, embed, and applet elements to determine whether they may trigger a fetch.

Note: Fetched plugin resources are handled in §4.1.4 Should response to request be blocked by Content Security Policy?.

This hook is missing from W3C’s HTML. <https://github.com/w3c/html/issues/547>
§4.2.5 Should navigation request of type from source in target be blocked by Content Security Policy? is called during the process a navigate fetch algorithm, and §4.2.6 Should navigation response to navigation request of type from source in target be blocked by Content Security Policy? is called during the process a navigate response algorithm to apply directive’s navigation checks, as well as inline checks for navigations to javascript:.

W3C’s HTML is not based on Fetch, and does not have a process a navigate response algorithm into which to hook. <https://github.com/w3c/html/issues/548>

4.2.1. Initialize a `Document`'s `CSP list`

Given a Document (document), and a response (response), the user agent performs the following steps in order to initialize document’s CSP list:

If response’s url’s scheme is a local scheme:
1. Let documents be an empty list.
2. If document has an embedding document (embedding), then add embedding to documents.
3. If document has an opener browsing context, then add its active document to documents.
4. For each doc in documents:
  1. For each policy in doc’s CSP list:
    1. Insert a copy of policy into document’s CSP list.
Note: local scheme includes about:, and this algorithm will therefore copy the embedding document’s policies for an iframe srcdoc Document.

Note: We do all this to ensure that a page cannot bypass its policy by embedding a frame or popping up a new window containing content it controls (blob: resources, or document.write()).
For each policy in response’s CSP list, insert policy into document’s CSP list.
For each policy in document’s CSP list:
1. For each directive in policy:
  1. Execute directive’s initialization algorithm on document and response.

4.2.2. Initialize a global object’s `CSP list`

Given a global object (global), and a response (response), the user agent performs the following steps in order to initialize global’s CSP list:

If response’s url’s scheme is a local scheme, or if global is a DedicatedWorkerGlobalScope:
1. Let owners be an empty list.
2. Add each of the items in global’s owner set to owners.
3. For each owner in owners:
  1. For each policy in owner’s CSP list:
    1. Insert a copy of policy into global’s CSP list.
Note: local scheme includes about:, and this algorithm will therefore copy the embedding document’s policies for an iframe srcdoc Document.
If global is a SharedWorkerGlobalScope or ServiceWorkerGlobalScope:
1. For each policy in response’s CSP list, insert policy into global’s CSP list.
If global is a WorkletGlobalScope:
1. Let owner be global’s owner document.
2. For each policy in owner’s CSP list:
  1. Insert a copy of policy into global’s CSP list.

4.2.3. Retrieve the CSP list of an `object`

To obtain object’s CSP list:

If object is a Document return object’s CSP list.
If object is a Window return object’s associated Document’s CSP list.
If object is a WorkerGlobalScope, return object’s CSP list.
If object is a WorkletGlobalScope, return object’s CSP list.
Return null.

4.2.4. Should `element`’s inline `type` behavior be blocked by Content Security Policy?

Given an Element (element), a string (type), and a string (source) this algorithm returns "Allowed" if the element is allowed to have inline definition of a particular type of behavior (script execution, style application, event handlers, etc.), and "Blocked" otherwise:

Note: The valid values for type are "script", "script attribute", "style", and "style attribute".

Assert: element is not null.
Let result be "Allowed".
For each policy in element’s Document's global object’s CSP list:
1. For each directive in policy’s directive set:
  1. If directive’s inline check returns "Allowed" when executed upon element, type, and source, skip to the next directive.
  2. Otherwise, let violation be the result of executing §2.4.1 Create a violation object for global, policy, and directive on the current settings object’s global object, policy, and "style-src" if type is "style" or "style-attribute", or "script-src" otherwise.
  3. Set violation’s resource to "inline".
  4. Set violation’s element to element.
  5. If directive’s value contains the expression "'report-sample'", then set violation’s sample to the substring of source containing its first 40 characters.
  6. Execute §5.3 Report a violation on violation.
  7. If policy’s disposition is "enforce", then set result to "Blocked".
Return result.

Given a request (navigation request), a string (type, either "form-submission" or "other"), and two browsing contexts (source and target), this algorithm return "Blocked" if the active policy blocks the navigation, and "Allowed" otherwise:

Let result be "Allowed".
For each policy in source’s active document’s CSP list:
1. For each directive in policy:
  1. If directive’s pre-navigation check returns "Allowed" when executed upon navigation request, type, source, and target, skip to the next directive.
  2. Otherwise, let violation be the result of executing §2.4.1 Create a violation object for global, policy, and directive on source’s relevant global object, policy, and directive’s name.
  3. Set violation’s resource to navigation request’s URL.
  4. Execute §5.3 Report a violation on violation.
  5. If policy’s disposition is "enforce", then set result to "Blocked".
If result is "Allowed", and if navigation request’s url’s scheme is javascript:
1. For each policy in source’s active document’s CSP List:
  1. For each directive in policy:
    1. If directive’s inline check returns "Allowed" when executed upon navigation request, type, source, and target, skip to the next directive.
  2. Otherwise, let violation be the result of executing §2.4.1 Create a violation object for global, policy, and directive on source’s relevant global object, policy, and directive’s name.
  3. Set violation’s resource to navigation request’s URL.
  4. Execute §5.3 Report a violation on violation.
  5. If policy’s disposition is "enforce", then set result to "Blocked".
Return result.

Given a request (navigation request),, a string (type, either "form-submission" or "other"), a response navigation response, and two browsing contexts (source and target), this algorithm returns "Blocked" if the active policy blocks the navigation, and "Allowed" otherwise:

Let result be "Allowed".
For each policy in navigation response’s CSP list:
1. For each directive in policy:
  1. If directive’s navigation response check returns "Allowed" when executed upon navigation request, type, navigation response, source, and target, skip to the next directive.
  2. Otherwise, let violation be the result of executing §2.4.1 Create a violation object for global, policy, and directive on null, policy, and directive’s name.
    
    Note: We use null for the global object, as no global exists: we haven’t processed the navigation to create a Document yet.
  3. Set violation’s resource to navigation response’s URL.
  4. Execute §5.3 Report a violation on violation.
  5. If policy’s disposition is "enforce", then set result to "Blocked".
Return result.

4.3. Integration with ECMAScript

ECMAScript defines a HostEnsureCanCompileStrings() abstract operation which allows the host environment to block the compilation of strings into ECMAScript code. This document defines an implementation of that abstract operation thich examines the relevant CSP list to determine whether such compilation ought to be blocked.

4.3.1. EnsureCSPDoesNotBlockStringCompilation(`callerRealm`, `calleeRealm`, `source`)

Given two realms (callerRealm and calleeRealm), and a string (source), this algorithm returns normally if string compilation is allowed, and throws an "EvalError" if not:

Let globals be a list containing callerRealm’s global object and calleeRealm’s global object.
For each global in globals:
1. Let result be "Allowed".
2. For each policy in global’s CSP list:
  1. Let source-list be null.
  2. If policy contains a directive whose name is "script-src", then set source-list to that directive's value.
    
    Otherwise if policy contains a directive whose name is "default-src", then set source-list to that directive’s value.
  3. If source-list is non-null, and does not contain a source expression which is an ASCII case-insensitive match for the string "'unsafe-eval'", then:
    1. Let violation be the result of executing §2.4.1 Create a violation object for global, policy, and directive on global, policy, and "script-src".
    2. Set violation’s resource to "inline".
    3. If source-list contains the expression "'report-sample'", then set violation’s sample to the substring of source containing its first 40 characters.
    4. Execute §5.3 Report a violation on violation.
    5. If policy’s disposition is "enforce", then set result to "Blocked".
3. If result is "Blocked", throw an EvalError exception.

HostEnsureCanCompileStrings() does not include the string which is going to be compiled as a parameter. We’ll also need to update HTML to pipe that value through to CSP. <https://github.com/tc39/ecma262/issues/938>

5. Reporting

When one or more of a policy’s directives is violated, a violation report may be generated and sent out to a reporting endpoint associated with the policy.

5.1. Violation DOM Events

enum SecurityPolicyViolationEventDisposition {
  "enforce", "report"
};

[Constructor(DOMString type, optional SecurityPolicyViolationEventInit eventInitDict)]
interface SecurityPolicyViolationEvent : Event {
    readonly    attribute DOMString      documentURI;
    readonly    attribute DOMString      referrer;
    readonly    attribute DOMString      blockedURI;
    readonly    attribute DOMString      violatedDirective;
    readonly    attribute DOMString      effectiveDirective;
    readonly    attribute DOMString      originalPolicy;
    readonly    attribute DOMString      sourceFile;
    readonly    attribute DOMString      sample;
    readonly    attribute SecurityPolicyViolationEventDisposition      disposition;
    readonly    attribute unsigned short statusCode;
    readonly    attribute long           lineNumber;
    readonly    attribute long           columnNumber;
};

dictionary SecurityPolicyViolationEventInit : EventInit {
    DOMString      documentURI;
    DOMString      referrer;
    DOMString      blockedURI;
    DOMString      violatedDirective;
    DOMString      effectiveDirective;
    DOMString      originalPolicy;
    DOMString      sourceFile;
    DOMString      sample;
    SecurityPolicyViolationEventDisposition      disposition;
    unsigned short statusCode;
    long           lineNumber;
    long           columnNumber;
};

5.2. Obtain the deprecated serialization of `violation`

Given a violation (violation), this algorithm returns a JSON text string representation of the violation, suitable for submission to a reporting endpoint associated with the deprecated report-uri directive.

Let object be a new JavaScript object with properties initialized as follows:

"document-uri"

The result of executing the URL serializer on violation’s url, with the exclude fragment flag set.

"referrer"

The result of executing the URL serializer on violation’s referrer, with the exclude fragment flag set.

"blocked-uri"

The result of executing the URL serializer on violation’s resource, with the exclude fragment flag set.

"effective-directive"

violation’s effective directive

"violated-directive"

violation’s effective directive

"original-policy"

The serialization of violation’s policy

"disposition"

The disposition of violation’s policy

"status-code"

violation’s status

"script-sample"

violation’s sample

Note: The name script-sample was chosen for compatibility with an earlier iteration of this feature which has shipped in Firefox since its initial implementation of CSP. Despite the name, this field will contain samples for non-script violations, like stylesheets. The data contained in a SecurityPolicyViolationEvent object, and in reports generated via the new report-to directive, is named in a more encompassing fashion: sample.
If violation’s source file is not null:
1. Set object’s "source-file" property to the result of executing the URL serializer on violation’s source file, with the exclude fragment flag set.
2. Set object’s "line-number" property to violation’s line number.
3. Set object’s "column-number" property to violation’s column number.
Assert: If object’s "blocked-uri" property is not "inline", then its "sample" property is the empty string.
Return the result of executing JSON.stringify() on object.

5.3. Report a `violation`

Given a violation (violation), this algorithm reports it to the endpoint specified in violation’s policy, and fires a SecurityPolicyViolationEvent at violation’s element, or at violation’s global object as described below:

Let global be violation’s global object.
Let target be violation’s element.
Queue a task to run the following steps:

Note: We "queue a task" here to ensure that the event targeting and dispatch happens after JavaScript completes execution of the task responsible for a given violation (which might manipulate the DOM).
1. If target is not null, and global is a Window, and target’s shadow-including root is not global’s associated Document, set target to null.
  
  Note: This ensures that we fire events only at elements connected to violation’s policy’s Document. If a violation is caused by an element which isn’t connected to that document, we’ll fire the event at the document rather than the element in order to ensure that the violation is visible to the document’s listeners.
2. If target is null:
  1. Set target be violation’s global object.
  2. If target is a Window, set target to target’s associated Document.
3. Fire an event named securitypolicyviolation that uses the SecurityPolicyViolationEvent interface at target with its attributes initialized as follows:
  
  documentURI
  
  The result of executing the URL serializer on violation’s url, with the exclude fragment flag set.
  
  referrer
  
  The result of executing the URL serializer on violation’s referrer, with the exclude fragment flag set.
  
  blockedURI
  
  The result of executing the URL serializer on violation’s resource, with the exclude fragment flag set.
  
  effectiveDirective
  
  violation’s effective directive
  
  violatedDirective
  
  violation’s effective directive
  
  originalPolicy
  
  violation’s policy
  
  disposition
  
  violation’s disposition
  
  sourceFile
  
  violation’s source file
  
  statusCode
  
  violation’s status
  
  lineNumber
  
  violation’s line number
  
  columnNumber
  
  violation’s column number
  
  sample
  
  violation’s sample
  
  bubbles
  
  true
  
  composed
  
  true
  
  Note: Both effectiveDirective and violatedDirective are the same value. This is intentional to maintain backwards compatibility.
  
  Note: We set the composed attribute, which means that this event can be captured on its way into, and will bubble its way out of a shadow tree. target, et al will be automagically scoped correctly for the main tree.
4. If violation’s policy’s directive set contains a directive named "report-uri" (directive):
  1. If violation’s policy’s directive set contains a directive named "report-to", skip the remaining substeps.
  2. Let endpoint be the result of executing the URL parser with directive’s value as the input, and violation’s url as the base URL.
  3. If endpoint is not a valid URL, skip the remaining substeps.
  4. Let request be a new request, initialized as follows:
    
    method
    
    "POST"
    
    url
    
    violation’s url
    
    origin
    
    violation’s global object’s relevant settings object’s origin
    
    window
    
    "no-window"
    
    client
    
    violation’s global object’s relevant settings object
    
    destination
    
    "report"
    
    initiator
    
    ""
    
    credentials mode
    
    "same-origin"
    
    keepalive flag
    
    "true"
    
    header list
    
    A header list containing a single header whose name is "Content-Type", and value is "application/csp-report"
    
    body
    
    The result of executing §5.2 Obtain the deprecated serialization of violation on violation
    
    redirect mode
    
    "error"
    
    Note: request’s mode defaults to "no-cors"; the response is ignored entirely.
  5. Fetch request. The result will be ignored.
  Note: All of this should be considered deprecated. It sends a single request per violation, which simply isn’t scalable. As soon as this behavior can be removed from user agents, it will be.
  
  Note: report-uri only takes effect if report-to is not present. That is, the latter overrides the former, allowing for backwards compatibility with browsers that don’t support the new mechanism.
5. If violation’s policy’s directive set contains a directive named "report-to" (directive):
  1. Let group be directive’s value.
  2. Let settings object be violation’s global object’s relevant settings object.
  3. Execute [REPORTING]'s Queue data as type for endpoint group on settings algorithm with the following arguments:
    
    data
    
    violation
    
    type
    
    "CSP"
    
    endpoint group
    
    group
    
    settings
    
    settings object

6. Content Security Policy Directives

This specification defines a number of types of directives which allow developers to control certain aspects of their sites' behavior. This document defines directives which govern resource fetching (in §6.1 Fetch Directives), directives which govern the state of a document (in §6.2 Document Directives), directives which govern aspects of navigation (in §6.3 Navigation Directives), and directives which govern reporting (in §6.4 Reporting Directives). These form the core of Content Security Policy; other directives are defined in a modular fashion in ancillary documents (see §6.5 Directives Defined in Other Documents for examples).

To mitigate the risk of cross-site scripting attacks, web developers SHOULD include directives that regulate sources of script and plugins. They can do so by including:

Both the script-src and object-src directives, or
a default-src directive

In either case, developers SHOULD NOT include either 'unsafe-inline', or data: as valid sources in their policies. Both enable XSS attacks by allowing code to be included directly in the document itself; they are best avoided completely.

6.1. Fetch Directives

Fetch directives control the locations from which certain resource types may be loaded. For instance, script-src allows developers to allow trusted sources of script to execute on a page, while font-src controls the sources of web fonts.

6.1.1. `child-src`

The child-src directive is deprecated. Authors who wish to regulate nested browsing contexts and workers SHOULD use the frame-src and worker-src directives, respectively.

The child-src directive governs the creation of nested browsing contexts (e.g. iframe and frame navigations) and Worker execution contexts. The syntax for the directive’s name and value is described by the following ABNF:

directive-name  = "child-src"
directive-value = serialized-source-list

This directive controls requests which will populate a frame or a worker. More formally, requests falling into one of the following categories:

destination is "document", and whose target browsing context is a nested browsing context (e.g. requests which will populate an iframe or frame element)
destination is either "serviceworker", "sharedworker", or "worker" (which are fed to the run a worker algorithm for ServiceWorker, SharedWorker, and Worker, respectively).

Given a page with the following Content Security Policy:

Content-Security-Policy: child-src https://example.com/

Fetches for the following code will all return network errors, as the URLs provided do not match child-src's source list:

<iframe src="https://example.org"></iframe>
<script>
  var blockedWorker = new Worker("data:application/javascript,...");
</script>

6.1.1.1. `child-src` Pre-request check

This directive’s pre-request check is as follows:

Given a request (request) and a policy (policy):

Let name be the result of executing §6.6.1.11 Get the effective directive for request on request.
If name is not frame-src, return "Allowed".
If policy contains a directive whose name is name, return "Allowed"
Return the result of executing the pre-request check for the directive whose name is name on request and policy, using this directive’s value for the comparison.

6.1.1.2. `child-src` Post-request check

This directive’s post-request check is as follows:

Given a request (request), a response (response), and a policy (policy):

Let name be the result of executing §6.6.1.11 Get the effective directive for request on request.
If name is not frame-src, return "Allowed".
If policy contains a directive whose name is name, return "Allowed"
Return the result of executing the post-request check for the directive whose name is name on request, response, and policy, using this directive’s value for the comparison.

6.1.2. `connect-src`

The connect-src directive restricts the URLs which can be loaded using script interfaces. The syntax for the directive’s name and value is described by the following ABNF:

directive-name  = "connect-src"
directive-value = serialized-source-list

This directive controls requests which transmit or receive data from other origins. This includes APIs like fetch(), [XHR], [EVENTSOURCE], [BEACON], and a's ping. This directive also controls WebSocket [WEBSOCKETS] connections, though those aren’t technically part of Fetch.

The connect-src directive allows you to ensure that these and similar sorts of connections are only opened to origins you trust. Sending a policy that defines a list of source expressions for this directive is straightforward. For example, to limit connections to only https://example.com, send the following header:

Content-Security-Policy: connect-src https://example.com/

Fetches for the following code will all return network errors, as the URLs provided do not match connect-src's source list:

<a ping="https://example.org">...
<script>
  var xhr = new XMLHttpRequest();
  xhr.open('GET', 'https://example.org/');
  xhr.send();

  var ws = new WebSocket("https://example.org/");

  var es = new EventSource("https://example.org/");

  navigator.sendBeacon("https://example.org/", { ... });
</script>

6.1.2.1. `connect-src` Pre-request check

This directive’s pre-request check is as follows:

Given a request (request) and a policy (policy):

Assert: policy is unused.
If request’s initiator is "fetch" or its destination is "":
1. If the result of executing §6.6.1.3 Does request match source list? on request and this directive’s value is "Does Not Match", return "Blocked".
Return "Allowed".

6.1.2.2. `connect-src` Post-request check

This directive’s post-request check is as follows:

Given a request (request), a response (response), and a policy (policy):

Assert: policy is unused.
If request’s initiator is "fetch" or its destination is "":
1. If the result of executing §6.6.1.4 Does response to request match source list? on response, request, and this directive’s value is "Does Not Match", return "Blocked".
Return "Allowed".

6.1.3. `default-src`

The default-src directive serves as a fallback for the other fetch directives. The syntax for the directive’s name and value is described by the following ABNF:

directive-name  = "default-src"
directive-value = serialized-source-list

If a default-src directive is present in a policy, its value will be used as the policy’s default source list. That is, given default-src 'none'; script-src 'self', script requests will use 'self' as the source list to match against. Other requests will use 'none'. This is spelled out in more detail in the §4.1.3 Should request be blocked by Content Security Policy? and §4.1.4 Should response to request be blocked by Content Security Policy? algorithms.

The following header:

Content-Security-Policy: default-src 'self'

will have the same behavior as the following header:

Content-Security-Policy: connect-src 'self';
                         font-src 'self';
                         frame-src 'self';
                         img-src 'self';
                         manifest-src 'self';
                         media-src 'self';
                         object-src 'self';
                         script-src 'self';
                         style-src 'self';
                         worker-src 'self'

That is, when default-src is set, every fetch directive that isn’t explicitly set will fall back to the value default-src specifies.

There is no inheritance. If a script-src directive is explicitly specified, for example, then the value of default-src has no influence on script requests. That is, the following header:

Content-Security-Policy: default-src 'self'; script-src https://example.com

will have the same behavior as the following header:

Content-Security-Policy: connect-src 'self';
                         font-src 'self';
                         frame-src 'self';
                         img-src 'self';
                         manifest-src 'self';
                         media-src 'self';
                         object-src 'self';
                         script-src https://example.com;
                         style-src 'self';
                         worker-src 'self'

Given this behavior, one good way to build a policy for a site would be to begin with a default-src of 'none', and to build up a policy from there which allowed only those resource types which are necessary for the particular page the policy will apply to.

6.1.3.1. `default-src` Pre-request check

This directive’s pre-request check is as follows:

Given a request (request) and a policy (policy):

Let name be the result of executing §6.6.1.11 Get the effective directive for request on request.
If name is null, return "Allowed".
If policy contains a directive whose name is name, return "Allowed".
If name is "frame-src", and policy contains a directive whose name is "child-src", return "Allowed".
If name is "worker-src", and policy contains a directive whose name is "script-src", return "Allowed".
Otherwise, return the result of executing the pre-request check for the directive whose name is name on request and policy, using this directive’s value for the comparison.

6.1.3.2. `default-src` Post-request check

This directive’s post-request check is as follows:

Given a request (request), a response (response), and a policy (policy):

Let name be the result of executing §6.6.1.11 Get the effective directive for request on request.
If name is null, return "Allowed".
If policy contains a directive whose name is name, return "Allowed".
If name is "frame-src", and policy contains a directive whose name is "child-src", return "Allowed".
If name is "worker-src", and policy contains a directive whose name is "script-src", return "Allowed".
Otherwise, return the result of executing the post-request check for the directive whose name is name on request, response, and policy, using this directive’s value for the comparison.

6.1.4. `font-src`

The font-src directive restricts the URLs from which font resources may be loaded. The syntax for the directive’s name and value is described by the following ABNF:

directive-name  = "font-src"
directive-value = serialized-source-list

Given a page with the following Content Security Policy:

Content-Security-Policy: font-src https://example.com/

Fetches for the following code will return a network errors, as the URL provided do not match font-src's source list:

<style>
  @font-face {
    font-family: "Example Font";
    src: url("https://example.org/font");
  }
  body {
    font-family: "Example Font";
  }
</style>

6.1.4.1. `font-src` Pre-request check

This directive’s pre-request check is as follows:

Given a request (request) and a policy (policy):

Assert: policy is unused.
If request’s destination is "font":
1. If the result of executing §6.6.1.3 Does request match source list? on request and this directive’s value is "Does Not Match", return "Blocked".
Return "Allowed".

6.1.4.2. `font-src` Post-request check

This directive’s post-request check is as follows:

Given a request (request), a response (response), and a policy (policy):

Assert: policy is unused.
If request’s destination is "font":
1. If the result of executing §6.6.1.4 Does response to request match source list? on response, request, and this directive’s value is "Does Not Match", return "Blocked".
Return "Allowed".

6.1.5. `frame-src`

The frame-src directive restricts the URLs which may be loaded into nested browsing contexts. The syntax for the directive’s name and value is described by the following ABNF:

directive-name  = "frame-src"
directive-value = serialized-source-list

Given a page with the following Content Security Policy:

Content-Security-Policy: frame-src https://example.com/

Fetches for the following code will return a network errors, as the URL provided do not match frame-src's source list:

<iframe src="https://example.org/">
</iframe>

6.1.5.1. `frame-src` Pre-request check

This directive’s pre-request check is as follows:

Given a request (request) and a policy (policy):

Assert: policy is unused.
If request’s destination is "document" and target browsing context is a nested browsing context:
1. If the result of executing §6.6.1.3 Does request match source list? on request and this directive’s value is "Does Not Match", return "Blocked".
Return "Allowed".

6.1.5.2. `frame-src` Post-request check

This directive’s post-request check is as follows:

Given a request (request), a response (response), and a policy (policy):

Assert: policy is unused.
If request’s destination is "document" and target browsing context is a nested browsing context:
1. If the result of executing §6.6.1.4 Does response to request match source list? on response, request, and this directive’s value is "Does Not Match", return "Blocked".
Return "Allowed".

6.1.6. `img-src`

The img-src directive restricts the URLs from which image resources may be loaded. The syntax for the directive’s name and value is described by the following ABNF:

directive-name  = "img-src"
directive-value = serialized-source-list

This directive controls requests which load images. More formally, this includes requests whose destination is "image" [FETCH].

Given a page with the following Content Security Policy:

Content-Security-Policy: img-src https://example.com/

Fetches for the following code will return a network errors, as the URL provided do not match img-src's source list:

<img src="https://example.org/img">

6.1.6.1. `img-src` Pre-request check

This directive’s pre-request check is as follows:

Given a request (request) and a policy (policy):

Assert: policy is unused.
If request’s destination is "image":
1. If the result of executing §6.6.1.3 Does request match source list? on request and this directive’s value is "Does Not Match", return "Blocked".
Return "Allowed".

6.1.6.2. `img-src` Post-request check

This directive’s post-request check is as follows:

Given a request (request), a response (response), and a policy (policy):

Assert: policy is unused.
If request’s destination is "image":
1. If the result of executing §6.6.1.4 Does response to request match source list? on response, request, and this directive’s value is "Does Not Match", return "Blocked".
Return "Allowed".

6.1.7. `manifest-src`

The manifest-src directive restricts the URLs from which application manifests may be loaded [APPMANIFEST]. The syntax for the directive’s name and value is described by the following ABNF:

directive-name  = "manifest-src"
directive-value = serialized-source-list

Given a page with the following Content Security Policy:

Content-Security-Policy: manifest-src https://example.com/

Fetches for the following code will return a network errors, as the URL provided do not match manifest-src's source list:

<link rel="manifest" href="https://example.org/manifest">

6.1.7.1. `manifest-src` Pre-request check

This directive’s pre-request check is as follows:

Given a request (request) and a policy (policy):

Assert: policy is unused.
If request’s destination is "manifest":
1. If the result of executing §6.6.1.3 Does request match source list? on request and this directive’s value is "Does Not Match", return "Blocked".
Return "Allowed".

6.1.7.2. `manifest-src` Post-request check

This directive’s post-request check is as follows:

Given a request (request), a response (response), and a policy (policy):

Assert: policy is unused.
If request’s destination is "manifest":
1. If the result of executing §6.6.1.4 Does response to request match source list? on response, request, and this directive’s value is "Does Not Match", return "Blocked".
Return "Allowed".

6.1.8. `media-src`

The media-src directive restricts the URLs from which video, audio, and associated text track resources may be loaded. The syntax for the directive’s name and value is described by the following ABNF:

directive-name  = "media-src"
directive-value = serialized-source-list

Given a page with the following Content Security Policy:

Content-Security-Policy: media-src https://example.com/

Fetches for the following code will return a network errors, as the URL provided do not match media-src's source list:

<audio src="https://example.org/audio"></audio>
<video src="https://example.org/video">
    <track kind="subtitles" src="https://example.org/subtitles">
</video>

6.1.8.1. `media-src` Pre-request check

This directive’s pre-request check is as follows:

Given a request (request) and a policy (policy):

Assert: policy is unused.
If request’s destination is one of "audio", "video", or "track":
1. If the result of executing §6.6.1.3 Does request match source list? on request and this directive’s value is "Does Not Match", return "Blocked".
Return "Allowed".

6.1.8.2. `media-src` Post-request check

This directive’s post-request check is as follows:

Given a request (request), a response (response), and a policy (policy):

Assert: policy is unused.
If request’s destination is one of "audio", "video", or "track":
1. If the result of executing §6.6.1.4 Does response to request match source list? on response, request, and this directive’s value is "Does Not Match", return "Blocked".
Return "Allowed".

6.1.9. `object-src`

The object-src directive restricts the URLs from which plugin content may be loaded. The syntax for the directive’s name and value is described by the following ABNF:

directive-name  = "object-src"
directive-value = serialized-source-list

Given a page with the following Content Security Policy:

Content-Security-Policy: object-src https://example.com/

Fetches for the following code will return a network errors, as the URL provided do not match object-src's source list:

<embed src="https://example.org/flash"></embed>
<object data="https://example.org/flash"></object>
<applet archive="https://example.org/flash"></applet>

If plugin content is loaded without an associated URL (perhaps an object element lacks a data attribute, but loads some default plugin based on the specified type), it MUST be blocked if object-src's value is 'none', but will otherwise be allowed.

Note: The object-src directive acts upon any request made on behalf of an object, embed, or applet element. This includes requests which would populate the nested browsing context generated by the former two (also including navigations). This is true even when the data is semantically equivalent to content which would otherwise be restricted by another directive, such as an object element with a text/html MIME type.

Note: When a plugin resource is navigated to directly (that is, as a plugin document in the top-level browsing context or a nested browsing context, and not as an embedded subresource via embed, object, or applet), any policy delivered along with that resource will be applied to the plugin document. This means, for instance, that developers can prevent the execution of arbitrary resources as plugin content by delivering the policy object-src 'none' along with a response. Given plugins' power (and the sometimes-interesting security model presented by Flash and others), this could mitigate the risk of attack vectors like Rosetta Flash.

6.1.9.1. `object-src` Pre-request check

This directive’s pre-request check is as follows:

Given a request (request) and a policy (policy):

Assert: policy is unused.
If request’s destination is "object" or "embed":
1. If the result of executing §6.6.1.3 Does request match source list? on request and this directive’s value is "Does Not Match", return "Blocked".
Return "Allowed".

6.1.9.2. `object-src` Post-request check

This directive’s post-request check is as follows:

Given a request (request), a response (response), and a policy (policy):

Assert: policy is unused.
If request’s destination is "object" or "embed":
1. If the result of executing §6.6.1.4 Does response to request match source list? on response, request, and this directive’s value is "Does Not Match", return "Blocked".
Return "Allowed".

6.1.10. `script-src`

The script-src directive restricts the locations from which scripts may be executed. This includes not only URLs loaded directly into script elements, but also things like inline script blocks and XSLT stylesheets [XSLT] which can trigger script execution. The syntax for the directive’s name and value is described by the following ABNF:

directive-name  = "script-src"
directive-value = serialized-source-list

The script-src directive governs four things:

Script requests MUST pass through §4.1.3 Should request be blocked by Content Security Policy?.
Script responses MUST pass through §4.1.4 Should response to request be blocked by Content Security Policy?.
Inline script blocks MUST pass through §4.2.4 Should element’s inline type behavior be blocked by Content Security Policy?. Their behavior will be blocked unless every policy allows inline script, either implicitly by not specifying a script-src (or default-src) directive, or explicitly, by specifying "unsafe-inline", a nonce-source or a hash-source that matches the inline block.
The following JavaScript execution sinks are gated on the "unsafe-eval" source expression:
- eval()
- Function()
- setTimeout() with an initial argument which is not callable.
- setInterval() with an initial argument which is not callable.
Note: If a user agent implements non-standard sinks like setImmediate() or execScript(), they SHOULD also be gated on "unsafe-eval".

6.1.10.1. `script-src` Pre-request check

This directive’s pre-request check is as follows:

Given a request (request) and a policy (policy):

If the result of executing §6.6.1.11 Get the effective directive for request on request is "worker-src", and policy contains a directive whose name is "worker-src", return "Allowed".

Note: If worker-src is present, we’ll defer to it when handling worker requests.
If request’s destination is script-like:
1. If the result of executing §6.6.1.2 Does nonce match source list? on request’s cryptographic nonce metadata and this directive’s value is "Matches", return "Allowed".
2. Let integrity expressions be the set of source expressions in this directive’s value that match the hash-source grammar.
3. If integrity expressions is not empty:
  1. Let integrity sources be the result of executing the algorithn defined in Subresource Integrity §parse-metadata on request’s integrity metadata. [SRI]
  2. If integrity sources is "no metadata" or an empty set, skip the remaining substeps.
  3. Let bypass due to integrity match be true.
  4. For each source in integrity sources:
    1. If this directive’s value does not contain a source expression whose hash-algorithm is a case-sensitive match for source’s hash-algo component, and whose base64-value is a case-sensitive match for source’s base64-value, then set bypass due to integrity match to false.
  5. If bypass due to integrity match is true, return "Allowed".
  Note: Here, we verify only that the request contains a set of integrity metadata which is a subset of the hash-source source expressions specified by this directive. We rely on the browser’s enforcement of Subresource Integrity [SRI] to block non-matching resources upon response.
4. If this directive’s value contains a source expression that is an ASCII case-insensitive match for the "'strict-dynamic'" keyword-source:
  1. If the request’s parser metadata is "parser-inserted", return "Blocked".
    
    Otherwise, return "Allowed".
    
    Note: "'strict-dynamic'" is explained in more detail in §8.2 Usage of "'strict-dynamic'".
5. If the result of executing §6.6.1.3 Does request match source list? on request and this directive’s value is "Does Not Match", return "Blocked".
Return "Allowed".

6.1.10.2. `script-src` Post-request check

This directive’s post-request check is as follows:

Given a request (request), a response (response), and a policy (policy):

If the result of executing §6.6.1.11 Get the effective directive for request on request is "worker-src", and policy contains a directive whose name is "worker-src", return "Allowed".

Note: If worker-src is present, we’ll defer to it when handling worker requests.
If request’s destination is script-like:
1. If the result of executing §6.6.1.2 Does nonce match source list? on request’s cryptographic nonce metadata and this directive’s value is "Matches", return "Allowed".
2. If this directive’s value contains "'strict-dynamic'", and request’s parser metadata is not "parser-inserted", return "Allowed".
3. If the result of executing §6.6.1.4 Does response to request match source list? on response, request, and this directive’s value is "Does Not Match", return "Blocked".
Return "Allowed".

6.1.10.3. `script-src` Inline Check

This directive’s inline check algorithm is as follows:

Given an Element (element), a string (type), and a string (source):

If type is "script attribute" or "script":
1. Assert: element is not null.
2. If the result of executing §6.6.2.3 Does element match source list for type and source? on element, this directive’s value, type, and source, is "Does Not Match", return "Blocked".
If type is "navigation":
1. Let unsafe-inline flag be false.
2. For each expression in this directive’s value:
  1. If expression matches the nonce-source or hash-source grammar, return "Blocked".
  2. If expression matches the keyword-source "'strict-dynamic'", return "Blocked".
  3. If expression matches the keyword-source "'unsafe-inline'", set unsafe-inline flag to true.
3. If unsafe-inline flag is false, return "Blocked".
Note: Navigating to a javascript: URL is allowed only in the presence of "'unsafe-inline'" that isn’t overridden by a nonce, hash, or "'strict-dynamic'".
Return "Allowed".

6.1.11. `style-src`

The style-src directive restricts the locations from which style may be applied to a Document. The syntax for the directive’s name and value is described by the following ABNF:

directive-name  = "style-src"
directive-value = serialized-source-list

The style-src directive governs several things:

Style requests MUST pass through §4.1.3 Should request be blocked by Content Security Policy?. This includes:
1. Stylesheet requests originating from a link element.
2. Stylesheet requests originating from the @import rule.
3. Stylesheet requests originating from a Link HTTP response header field [RFC8288].
Responses to style requests MUST pass through §4.1.4 Should response to request be blocked by Content Security Policy?.
Inline style blocks MUST pass through §4.2.4 Should element’s inline type behavior be blocked by Content Security Policy?. The styles will be blocked unless every policy allows inline style, either implicitly by not specifying a style-src (or default-src) directive, or explicitly, by specifying "unsafe-inline", a nonce-source or a hash-source that matches the inline block.
The following CSS algorithms are gated on the unsafe-eval source expression:
This would include, for example, all invocations of CSSOM’s various cssText setters and insertRule methods [CSSOM] [HTML].

This needs to be better explained. <https://github.com/w3c/webappsec-csp/issues/212>

6.1.11.1. `style-src` Pre-request Check

This directive’s pre-request check is as follows:

Given a request (request) and a policy (policy):

Assert: policy is unused.
If request’s destination is "style":
1. If the result of executing §6.6.1.2 Does nonce match source list? on request’s cryptographic nonce metadata and this directive’s value is "Matches", return "Allowed".
2. If the result of executing §6.6.1.3 Does request match source list? on request and this directive’s value is "Does Not Match", return "Blocked".
Return "Allowed".

6.1.11.2. `style-src` Post-request Check

This directive’s post-request check is as follows:

Given a request (request), a response (response), and a policy (policy):

Assert: policy is unused.
If request’s destination is "style":
1. If the result of executing §6.6.1.2 Does nonce match source list? on request’s cryptographic nonce metadata and this directive’s value is "Matches", return "Allowed".
2. If the result of executing §6.6.1.4 Does response to request match source list? on response, request, and this directive’s value is "Does Not Match", return "Blocked".
Return "Allowed".

6.1.11.3. `style-src` Inline Check

This directive’s inline check algorithm is as follows:

Given an Element (element), a string (type), and a string (source):

If type is "style" or "style attribute":
1. If the result of executing §6.6.2.3 Does element match source list for type and source? on element, this directive’s value, type, and source, is "Does Not Match", return "Blocked".
Return "Allowed".

This directive’s initialization algorithm is as follows:

Do something interesting to the execution context in order to lock down interesting CSSOM algorithms. I don’t think CSSOM gives us any hooks here, so let’s work with them to put something reasonable together.

6.1.12. `worker-src`

The worker-src directive restricts the URLs which may be loaded as a Worker, SharedWorker, or ServiceWorker. The syntax for the directive’s name and value is described by the following ABNF:

directive-name  = "worker-src"
directive-value = serialized-source-list

Given a page with the following Content Security Policy:

Content-Security-Policy: worker-src https://example.com/

Fetches for the following code will return a network errors, as the URL provided do not match worker-src's source list:

<script>
  var blockedWorker = new Worker("data:application/javascript,...");
  blockedWorker = new SharedWorker("https://example.org/");
  navigator.serviceWorker.register('https://example.org/sw.js');
</script>

6.1.12.1. `worker-src` Pre-request Check

This directive’s pre-request check is as follows:

Given a request (request) and a policy (policy):

Assert: policy is unused.
If request’s destination is one of "serviceworker", "sharedworker", or "worker":
1. If the result of executing §6.6.1.3 Does request match source list? on request and this directive’s value is "Does Not Match", return "Blocked".
Return "Allowed".

6.1.12.2. `worker-src` Post-request Check

This directive’s post-request check is as follows:

Given a request (request), a response (response), and a policy (policy):

Assert: policy is unused.
If request’s destination is one of "serviceworker", "sharedworker", or "worker":
1. If the result of executing §6.6.1.4 Does response to request match source list? on response, request, and this directive’s value is "Does Not Match", return "Blocked".
Return "Allowed".

6.2. Document Directives

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

6.2.1. `base-uri`

The base-uri directive restricts the URLs which can be used in a Document's base element. The syntax for the directive’s name and value is described by the following ABNF:

directive-name  = "base-uri"
directive-value = serialized-source-list

The following algorithm is called during HTML’s set the frozen base url algorithm in order to monitor and enforce this directive:

6.2.1.1. Is `base` allowed for `document`?

Given a URL (base), and a Document (document), this algorithm returns "Allowed" if base may be used as the value of a base element’s href attribute, and "Blocked" otherwise:

For each policy in document’s global object’s csp list:
1. Let source list be null.
2. If a directive whose name is "base-uri" is present in policy’s directive set, set source list to that directive’s value.
3. If source list is null, skip to the next policy.
4. If the result of executing §6.6.1.5 Does url match source list in origin with redirect count? on base, source list, document’s fallback base URL’s origin, and 0 is "Does Not Match":
  1. Let violation be the result of executing §2.4.1 Create a violation object for global, policy, and directive on document’s global object, policy, and "base-uri".
  2. Set violation’s resource to "inline".
  3. Execute §5.3 Report a violation on violation.
  4. If policy’s disposition is "enforce", return "Blocked".
Note: We compare against the fallback base URL in order to deal correctly with things like an iframe srcdoc Document which has been sandboxed into an opaque origin.
Return "Allowed".

6.2.2. `plugin-types`

The plugin-types directive restricts the set of plugins that can be embedded into a document by limiting the types of resources which can be loaded. The directive’s syntax is described by the following ABNF grammar:

directive-name  = "plugin-types"
directive-value = media-type-list

media-type-list = media-type *( RWS media-type )
media-type = type "/" subtype
; type and subtype are defined in RFC 2045

If a plugin-types directive is present, instantiation of an embed or object element will fail if any of the following conditions hold:

The element does not explicitly declare a valid MIME type via a type attribute.
The declared type does not match one of the items in the directive’s value.
The fetched resource does not match the declared type.

Given a page with the following Content Security Policy:

Content-Security-Policy: plugin-types application/pdf

Fetches for the following code will all return network errors:

<!-- No 'type' declaration -->
<object data="https://example.com/flash"></object>

<!-- Non-matching 'type' declaration -->
<object data="https://example.com/flash" type="application/x-shockwave-flash"></object>

<!-- Non-matching resource -->
<object data="https://example.com/flash" type="application/pdf"></object>

If the page allowed Flash content by sending the following header:

Content-Security-Policy: plugin-types application/x-shockwave-flash

Then the second item above would load successfully:

<!-- Matching 'type' declaration and resource -->
<object data="https://example.com/flash" type="application/x-shockwave-flash"></object>

6.2.2.1. `plugin-types` Post-Request Check

This directive’s post-request check algorithm is as follows:

Given a request (request), a response (response), and a policy (policy):

Assert: policy is unused.
If request’s destination is either "object" or "embed":
1. Let type be the result of extracting a MIME type from response’s header list.
2. If type is not an ASCII case-insensitive match for any item in this directive’s value, return "Blocked".
Return "Allowed".

6.2.2.2. Should `plugin element` be blocked a priori by Content Security Policy?:

Given an Element (plugin element), this algorithm returns "Blocked" or "Allowed" based on the element’s type attribute and the policy applied to its document:

For each policy in plugin element’s node document’s CSP list:
1. If policy contains a directive (directive) whose name is plugin-types:
  1. Let type be "application/x-java-applet" if plugin element is an applet element, or plugin element’s type attribute’s value if present, or "null" otherwise.
  2. Return "Blocked" if any of the following are true:
    1. type is null.
    2. type is not a valid MIME type.
    3. type is not an ASCII case-insensitive match for any item in directive’s value.
Return "Allowed".

6.2.3. `sandbox`

The sandbox directive specifies an HTML sandbox policy which the user agent will apply to a resource, just as though it had been included in an iframe with a sandbox property.

The directive’s syntax is described by the following ABNF grammar, with the additional requirement that each token value MUST be one of the keywords defined by HTML specification as allowed values for the iframe sandbox attribute [HTML].

directive-name  = "sandbox"
directive-value = "" / token *( RWS token )

This directive has no reporting requirements; it will be ignored entirely when delivered in a Content-Security-Policy-Report-Only header, or within a meta element.

6.2.3.1. `sandbox` Response Check

This directive’s response check algorithm is as follows:

Given a request (request), a response (response), and a policy (policy):

Assert: response is unused.
If policy’s disposition is not "enforce", then return "Allowed".
If request’s destination is one of "serviceworker", "sharedworker", or "worker":
1. If the result of the Parse a sandboxing directive algorithm using this directive’s value as the input contains either the sandboxed scripts browsing context flag or the sandboxed origin browsing context flag flags, return "Blocked".
  
  Note: This will need to change if we allow Workers to be sandboxed into unique origins, which seems like a pretty reasonable thing to do.
Return "Allowed".

6.2.3.2. `sandbox` Initialization

This directive’s initialization algorithm is responsible for adjusting a Document's forced sandboxing flag set according to the sandbox values present in its policies, as follows:

Given a Document or global object (context), a response (response), and a policy (policy):

Assert: response is unused.
If policy’s disposition is not "enforce", or context is not a Document, then abort this algorithm.

Note: This will need to change if we allow Workers to be sandboxed, which seems like a pretty reasonable thing to do.
Parse a sandboxing directive using this directive’s value as the input, and context’s forced sandboxing flag set as the output.

6.2.4. `disown-opener`

The disown-opener directive ensures that a resource will disown its opener when navigated to. The directive’s syntax is described by the following ABNF grammar:

directive-name  = "disown-opener"
directive-value = ""

This directive has no reporting requirements; it will be ignored entirely when delivered in a Content-Security-Policy-Report-Only header, or within a meta element.

Not sure this is the right model. We need to ensure that we take care of the inverse as well, and there might be a cleverer syntax that could encompass both a document’s opener, and a document’s openees. disown-openee is weird. Maybe disown 'opener' 'openee'? Do we need origin restrictions on either/both?

6.2.4.1. `disown-opener` Initialization

This directive’s initialization algorithm is as follows:

Given a Document or global object (context), a response (response), and a policy (policy):

Assert: response and policy are unused.
If context’s responsible browsing context has an opener browsing context, disown its opener.

What should this do in an iframe? Anything?

6.3.1. `form-action`

The form-action directive restricts the URLs which can be used as the target of a form submissions from a given context. The directive’s syntax is described by the following ABNF grammar:

directive-name  = "form-action"
directive-value = serialized-source-list

6.3.1.1. `form-action` Pre-Navigation Check

Given a request (request), a string (type, "form-submission or "other") and two browsing contexts (source and target), this algorithm returns "Blocked" if one or more of the ancestors of target violate the frame-ancestors directive delivered with the response, and "Allowed" otherwise. This constitutes the form-action' directive’s pre-navigation check:

Assert: source and target are unused in this algorithm, as form-action is concerned only with details of the outgoing request.
If type is "form-submission":
1. If the result of executing §6.6.1.3 Does request match source list? on request and this directive’s value is "Does Not Match", return "Blocked".
Return "Allowed".

6.3.2. `frame-ancestors`

The frame-ancestors directive restricts the URLs which can embed the resource using frame, iframe, object, embed, or applet element. Resources can use this directive to avoid many UI Redressing [UISECURITY] attacks, by avoiding the risk of being embedded into potentially hostile contexts.

The directive’s syntax is described by the following ABNF grammar:

directive-name  = "frame-ancestors"
directive-value = ancestor-source-list

ancestor-source-list = ( ancestor-source *( RWS ancestor-source) ) / "'none'"
ancestor-source      = scheme-source / host-source / "'self'"

The frame-ancestors directive MUST be ignored when contained in a policy declared via a meta element.

Note: The frame-ancestors directive’s syntax is similar to a source list, but frame-ancestors will not fall back to the default-src directive’s value if one is specified. That is, a policy that declares default-src 'none' will still allow the resource to be embedded by anyone.

Given a request (request), a response (navigation response) and two browsing contexts (source and target), this algorithm returns "Blocked" if one or more of the ancestors of target violate the frame-ancestors directive delivered with the response, and "Allowed" otherwise. This constitutes the frame-ancestors' directive’s navigation response check:

Assert: request, navigation response, and source are unused in this algorithm, as frame-ancestors is concerned only with target’s ancestors.
If target is not a nested browsing context, return "Allowed".
Let current be target.
While current has a parent browsing context (parent):
1. Set current to parent.
2. Let origin be the result of executing the URL parser on the ASCII serialization of parent’s active document’s relevant settings object’s origin.
3. If §6.6.1.5 Does url match source list in origin with redirect count? returns Does Not Match when executed upon origin, this directive’s value, navigation response’s url’s origin, and 0, return "Blocked".
Return "Allowed".

6.3.2.2. Relation to `X-Frame-Options`

This directive is similar to the X-Frame-Options header that several user agents have implemented. The 'none' source expression is roughly equivalent to that header’s DENY, 'self' to SAMEORIGIN, and so on. The major difference is that many user agents implement SAMEORIGIN such that it only matches against the top-level document’s location, while the frame-ancestors directive checks against each ancestor. If _any_ ancestor doesn’t match, the load is cancelled. [RFC7034]

In order to allow backwards-compatible deployment, the frame-ancestors directive _obsoletes_ the X-Frame-Options header. If a resource is delivered with an policy that includes a directive named frame-ancestors and whose disposition is "enforce", then the X-Frame-Options header MUST be ignored.

Spell this out in more detail as part of defining X-Frame-Options integration with the process a navigate response algorithm. <https://github.com/whatwg/html/issues/1230>

The navigation-to directive restricts the URLs to which a document can navigate by any means (a, form, window.location, window.open, etc.). The directive’s syntax is described by the following ABNF grammar:

directive-name  = "navigation-to"
directive-value = serialized-source-list

Should we use ancestor-source-list (basically, origins as opposed to paths?) It doesn’t appear that blocking navigation targets is any worse than blocking any other request type with regard to leakage. Given the redirect behavior, this devolves to an origin check in the presence of a malicious party anyway...

Given a request (request), a string (type, "form-submission or "other") and two browsing contexts (source and target), this algorithm returns "Blocked" if the navigation violates the navigation-to directive’s constraints, and "Allowed" otherwise. This constitutes the navigation-to' directive’s pre-navigation check:

Assert: source and target are unused in this algorithm, as navigation-to is concerned only with details of the outgoing request. Likewise, type is unused, as all navigation requests are treated identically.
If the result of executing §6.6.1.3 Does request match source list? on request and this directive’s value is "Does Not Match", return "Blocked".
Return "Allowed".

6.4. Reporting Directives

Various algorithms in this document hook into the reporting process by constructing a violation object via §2.4.2 Create a violation object for request, policy, and directive or §2.4.1 Create a violation object for global, policy, and directive, and passing that object to §5.3 Report a violation to deliver the report.

6.4.1. `report-uri`

Note: The report-uri directive is deprecated. Please use the report-to directive instead. If the latter directive is present, this directive will be ignored. To ensure backwards compatibility, we suggest specifying both, like this:

Content-Security-Policy: ...; report-uri https://endpoint.com; report-to groupname

The report-uri directive defines a set of endpoints to which violation reports will be sent when particular behaviors are prevented.

directive-name  = "report-uri"
directive-value = uri-reference *( RWS uri-reference )

; The uri-reference grammar is defined in Section 4.1 of RFC 3986.

The directive has no effect in and of itself, but only gains meaning in combination with other directives.

6.4.2. `report-to`

The report-to directive defines a reporting group to which violation reports ought to be sent [REPORTING]. The directive’s behavior is defined in §5.3 Report a violation. The directive’s name and value are described by the following ABNF:

directive-name  = "report-to"
directive-value = token

6.5. Directives Defined in Other Documents

This document defines a core set of directives, and sets up a framework for modular extension by other specifications. At the time this document was produced, the following stable documents extend CSP:

[MIX] defines block-all-mixed-content
[UPGRADE-INSECURE-REQUESTS] defines upgrade-insecure-requests
[SRI] defines require-sri-for

Extensions to CSP MUST register themselves via the process outlined in [RFC7762]. In particular, note the criteria discussed in Section 4.2 of that document.

New directives SHOULD use the pre-request check, post-request check, response check, and initialization hooks in order to integrate themselves into Fetch and HTML.

6.6. Matching Algorithms

6.6.1. URL Matching

6.6.1.1. Does `request` violate `policy`?

Given a request (request) and a policy (policy), this algorithm returns the violated directive if the request violates the policy, and "Does Not Violate" otherwise.

Let violates be "Does Not Violate".
For each directive in policy:
1. Let result be the result of executing directive’s pre-request check on request and policy.
2. If result is "Blocked", then let violates be directive.
Return violates.

6.6.1.2. Does `nonce` match `source list`?

Given a request’s cryptographic nonce metadata (nonce) and a source list (source list), this algorithm returns "Matches" if the nonce matches one or more source expressions in the list, and "Does Not Match" otherwise:

Assert: source list is not null.
If nonce is the empty string, return "Does Not Match".
For each expression in source list:
1. If expression matches the nonce-source grammar, and nonce is a case-sensitive match for expression’s base64-value part, return "Matches".
Return "Does Not Match".

6.6.1.3. Does `request` match `source list`?

Given a request (request), and a source list (source list), this algorithm returns the result of executing §6.6.1.5 Does url match source list in origin with redirect count? on request’s current url, source list, request’s origin, and request’s redirect count.

Note: This is generally used in directives' pre-request check algorithms to verify that a given request is reasonable.

6.6.1.4. Does `response` to `request` match `source list`?

Given a request (request), and a source list (source list), this algorithm returns the result of executing §6.6.1.5 Does url match source list in origin with redirect count? on response’s url, source list, request’s origin, and request’s redirect count.

Note: This is generally used in directives' post-request check algorithms to verify that a given response is reasonable.

6.6.1.5. Does `url` match `source list` in `origin` with `redirect count`?

Given a URL (url), a source list (source list), an origin (origin), and a number (redirect count), this algorithm returns "Matches" if the URL matches one or more source expressions in source list, or "Does Not Match" otherwise:

Assert: source list is not null.
If source list is an empty list, return "Does Not Match".
If source list contains a single item which is an ASCII case-insensitive match for the string "'none'", return "Does Not Match".

Note: An empty source list (that is, a directive without a value: script-src, as opposed to script-src host1) is equivalent to a source list containing 'none', and will not match any URL.
For each expression in source list:
1. If §6.6.1.6 Does url match expression in origin with redirect count? returns "Matches" when executed upon url, expression, origin, and redirect count, return "Matches".
Return "Does Not Match".

6.6.1.6. Does `url` match `expression` in `origin` with `redirect count`?

Given a URL (url), a source expression (expression), an origin (origin), and a number (redirect count), this algorithm returns "Matches" if url matches expression, and "Does Not Match" otherwise.

Note: origin is the origin of the resource relative to which the expression should be resolved. "'self'", for instance, will have distinct meaning depending on that bit of context.

If expression is the string "*", return "Matches" if one or more of the following conditions is met:
1. url’s scheme is a network scheme.
2. url’s scheme is the same as origin’s scheme.
Note: This logic means that in order to allow a resource from a non-network scheme, it has to be either explicitly specified (e.g. default-src * data: custom-scheme-1: custom-scheme-2:), or the protected resource must be loaded from the same scheme.
If expression matches the scheme-source or host-source grammar:
1. If expression has a scheme-part, and it does not scheme-part match url’s scheme, return "Does Not Match".
2. If expression matches the scheme-source grammar, return "Matches".
If expression matches the host-source grammar:
1. If url’s host is null, return "Does Not Match".
2. If expression does not have a scheme-part, and origin’s scheme does not scheme-part match url’s scheme, return "Does Not Match".
  
  Note: As with scheme-part above, we allow schemeless host-source expressions to be upgraded from insecure schemes to secure schemes.
3. If expression’s host-part does not host-part match url’s host, return "Does Not Match".
4. Let port-part be expression’s port-part if present, and null otherwise.
5. If port-part does not port-part match url’s port and url’s scheme, return "Does Not Match".
6. If expression contains a non-empty path-part, and redirect count is 0, then:
  1. Let path be the resulting of joining url’s path on the U+002F SOLIDUS character (/).
  2. If expression’s path-part does not path-part match path, return "Does Not Match".
7. Return "Matches".
If expression is an ASCII case-insensitive match for "'self'", return "Matches" if one or more of the following conditions is met:
1. origin is the same as url’s origin
2. origin’s host is the same as url’s host, origin’s port and url’s port are either the same or the default ports for their respective schemes, and one or more of the following conditions is met:
  1. url’s scheme is "https" or "wss"
  2. origin’s scheme is "http"
Note: Like the scheme-part logic above, the "'self'" matching algorithm allows upgrades to secure schemes when it is safe to do so. We limit these upgrades to endpoints running on the default port for a particular scheme or a port that matches the origin of the protected resource, as this seems sufficient to deal with upgrades that can be reasonably expected to succeed.
Return "Does Not Match".

6.6.1.7. `scheme-part` matching

An ASCII string scheme-part matches another ASCII string if a CSP source expression that contained the first as a scheme-part could potentially match a URL containing the latter as a scheme. For example, we say that "http" scheme-part matches "https".

Note: The matching relation is asymmetric. For example, the source expressions https: and https://example.com/ do not match the URL http://example.com/. We always allow a secure upgrade from an explicitly insecure expression. script-src http: is treated as equivalent to script-src http: https:, script-src http://example.com to script-src http://example.com https://example.com, and connect-src ws: to connect-src ws: wss:.

More formally, two ASCII strings (A and B) are said to scheme-part match if the following algorithm returns "Matches":

If one of the following is true, return "Matches":
1. A is an ASCII case-insensitive match for B.
2. A is an ASCII case-insensitive match for "http", and B is an ASCII case-insensitive match for "https".
3. A is an ASCII case-insensitive match for "ws", and B is an ASCII case-insensitive match for "wss", "http", or "https".
4. A is an ASCII case-insensitive match for "wss", and B is an ASCII case-insensitive match for "https".
Return "Does Not Match".

6.6.1.8. `host-part` matching

An ASCII string host-part matches another ASCII string if a CSP source expression that contained the first as a host-part could potentially match a URL containing the latter as a host. For example, we say that "www.example.com" host-part matches "www.example.com".

More formally, two ASCII strings (A and B) are said to host-part match if the following algorithm returns "Matches":

Note: The matching relation is asymmetric. That is, A matching B does not mean that B will match A. For example, *.example.com host-part matches www.example.com, but www.example.com does not host-part match *.example.com.

If the first character of A is an U+002A ASTERISK character (*):
1. Let remaining be the result of removing the leading ("*") from A.
2. If remaining (including the leading U+002E FULL STOP character (.)) is an ASCII case-insensitive match for the rightmost characters of B, then return "Matches". Otherwise, return "Does Not Match".
If A is not an ASCII case-insensitive match for B, return "Does Not Match".
If A matches the IPv4address rule from [RFC3986], and is not "127.0.0.1"; or if A is an IPv6 address, return "Does Not Match".

Note: A future version of this specification may allow literal IPv6 and IPv4 addresses, depending on usage and demand. Given the weak security properties of IP addresses in relation to named hosts, however, authors are encouraged to prefer the latter whenever possible.
Return "Matches".

6.6.1.9. `port-part` matching

An ASCII string (port A) port-part matches two other ASCII strings (port B and scheme B) if a CSP source expression that contained the first as a port-part could potentially match a URL containing the latter as port and scheme. For example, "80" port-part matches matches "80"/"http".

If port A is empty:
1. If port B is the default port for scheme B, return "Matches". Otherwise, return "Does Not Match".
If port A is equal to "*", return "Matches".
If port A is a case-sensitive match for port B, return "Matches".
If port B is empty:
1. If port A is the default port for scheme B, return "Matches". Otherwise, return "Does not Match".
Return "Does Not Match".

6.6.1.10. `path-part` matching

An ASCII string (path A) path-part matches another ASCII string (path B) if a CSP source expression that contained the first as a path-part could potentially match a URL containing the latter as a path. For example, we say that "/subdirectory/" path-part matches "/subdirectory/file".

Note: The matching relation is asymmetric. That is, path A matching path B does not mean that path B will match path A.

If path A is empty, return "Matches".
If path A consists of one character that is equal to the U+002F SOLIDUS character (/) and path B is empty, return "Matches".
Let exact match be false if the final character of path A is the U+002F SOLIDUS character (/), and true otherwise.
Let path list A and path list B be the result of strictly splitting path A and path B respestively on the U+002F SOLIDUS character (/).
If path list A has more items than path list B, return "Does Not Match".
If exact match is true, and path list A does not have the same number of items as path list B, return "Does Not Match".
If exact match is false:
1. Assert: the final item in path list A is the empty string.
2. Remove the final item from path list A.
For each piece A in path list A:
1. Let piece B be the next item in path list B.
2. Percent decode piece A.
3. Percent decode piece B.
4. If piece A is not a case-sensitive match for piece B, return "Does Not Match".
Return "Matches".

6.6.1.11. Get the effective directive for `request`

Each fetch directive controls a specific destination of request. Given a request (request), the following algorithm returns either null or the name of the request’s effective directive:

Switch on request’s destination, and execute the associated steps:
""
1. If the request’s initiator is the empty string, return connect-src.
"manifest"
1. Return manifest-src.
"object"
"embed"
1. Return object-src.
"document"
1. If the request’s target browsing context is a nested browsing context, return frame-src.
"audio"
"track"
"video"
1. Return media-src.
"font"
1. Return font-src.
"image"
1. Return img-src.
"style"
1. Return style-src.
"script"
"xslt"
1. Return script-src.
"sharedworker"
"worker"
1. Return worker-src.
Return null.

6.6.2. Element Matching Algorithms

6.6.2.1. Is `element` nonceable?

Given an Element (element), this algorithm returns "Nonceable" if a nonce-source expression can match the element (as discussed in §7.2 Nonce Stealing), and "Not Nonceable" if such expressions should not be applied.

If element does not have an attribute named "nonce", return "Not Nonceable".
If element is a script element, then for each attribute in element:
1. If attribute’s name is an ASCII case-insensitive match for the string "<script" or the string "<style", return "Not Nonceable".
2. If attribute’s value contains an ASCII case-insensitive match the string "<script" or the string "<style", return "Not Nonceable".
If element had a duplicate-attribute parse error during tokenization, return "Not Nonceable".

We need some sort of hook in HTML to record this error if we’re planning on using it here. <https://github.com/whatwg/html/issues/3257>
Return "Nonceable".

This processing is meant to mitigate the risk of dangling markup attacks that steal the nonce from an existing element in order to load injected script. It is fairly expensive, however, as it requires that we walk through all attributes and their values in order to determine whether the script should execute. Here, we try to minimize the impact by doing this check only for script elements when a nonce is present, but we should probably consider this algorithm as "at risk" until we know its impact. <https://github.com/w3c/webappsec-csp/issues/98>

6.6.2.2. Does a source list allow all inline behavior for `type`?

A source list allows all inline behavior of a given type if it contains the keyword-source expression 'unsafe-inline', and does not override that expression as described in the following algorithm:

Given a source list (list) and a string (type), the following algorithm returns "Allows" if all inline content of a given type is allowed and "Does Not Allow" otherwise.

Let allow all inline be false.
For each expression in list:
1. If expression matches the nonce-source or hash-source grammar, return "Does Not Allow".
2. If type is "script" or "script attribute" and expression matches the keyword-source "'strict-dynamic'", return "Does Not Allow".
  
  Note: 'strict-dynamic' only applies to scripts, not other resource types. Usage is explained in more detail in §8.2 Usage of "'strict-dynamic'".
3. If expression is an ASCII case-insensitive match for the keyword-source "'unsafe-inline'", set allow all inline to true.
If allow all inline is true, return "Allows". Otherwise, return "Does Not Allow".

Source lists that allow all inline behavior:

'unsafe-inline' http://a.com http://b.com
'unsafe-inline'

Source lists that do not allow all inline behavior due to the presence of nonces and/or hashes, or absence of 'unsafe-inline':

'sha512-321cba' 'nonce-abc'
http://example.com 'unsafe-inline' 'nonce-abc'

Source lists that do not allow all inline behavior when type is 'script' or 'script attribute' due to the presence of 'strict-dynamic', but allow all inline behavior otherwise:

'unsafe-inline' 'strict-dynamic'
http://example.com 'strict-dynamic' 'unsafe-inline'

6.6.2.3. Does `element` match source list for `type` and `source`?

Given an Element (element), a source list (list), a string (type), and a string (source), this algorithm returns "Matches" or "Does Not Match".

Assert: source contains the value of a script element’s text IDL attribute, the value of a style element’s textContent IDL attribute, or the value of one of a script element’s event handler IDL attribute.

Note: This means that source will be interpreted with the encoding of the page in which it is embedded. See the integration points in §4.2 Integration with HTML for more detail.
If §6.6.2.2 Does a source list allow all inline behavior for type? returns "Allows" given list and type, return "Matches".
If type is "script" or "style", and §6.6.2.1 Is element nonceable? returns "Nonceable" when executed upon element:
1. For each expression in list:
  1. If expression matches the nonce-source grammar, and element has a nonce attribute whose value is a case-sensitive match for expression’s base64-value part, return "Matches".
Note: Nonces only apply to inline script and inline style, not to attributes of either element.
Let hashes match attributes be false.
For each expression in list:
1. If expression is an ASCII case-insensitive match for the keyword-source "'unsafe-hashed-attributes'", set hashes match attributes to true. Break out of the loop.
If type is "script" or "style", or hashes match attributes is true:
1. For each expression in list:
  1. If expression matches the hash-source grammar:
    1. Let algorithm be null.
    2. If expression’s hash-algorithm part is an ASCII case-insensitive match for "sha256", set algorithm to SHA-256.
    3. If expression’s hash-algorithm part is an ASCII case-insensitive match for "sha384", set algorithm to SHA-384.
    4. If expression’s hash-algorithm part is an ASCII case-insensitive match for "sha512", set algorithm to SHA-512.
    5. If algorithm is not null:
      1. Let actual be the result of base64 encoding the result of applying algorithm to source.
      2. Let expected be expression’s base64-value part, with all '-' characters replaced with '+', and all '_' characters replaced with '/'.
        
        Note: This replacement normalizes hashes expressed in base64url encoding into base64 encoding for matching.
      3. If actual is a case-sensitive match for expected, return "Matches".
Note: Hashes apply to inline script and inline style. If the "'unsafe-hashed-attributes'" source expression is present, they will also apply to event handlers and style attributes.
Return "Does Not Match".

7. Security and Privacy Considerations

7.1. Nonce Reuse

Nonces override the other restrictions present in the directive in which they’re delivered. It is critical, then, that they remain unguessable, as bypassing a resource’s policy is otherwise trivial.

If a server delivers a nonce-source expression as part of a policy, the server MUST generate a unique value each time it transmits a policy. The generated value SHOULD be at least 128 bits long (before encoding), and SHOULD be generated via a cryptographically secure random number generator in order to ensure that the value is difficult for an attacker to predict.

Note: Using a nonce to allow inline script or style is less secure than not using a nonce, as nonces override the restrictions in the directive in which they are present. An attacker who can gain access to the nonce can execute whatever script they like, whenever they like. That said, nonces provide a substantial improvement over 'unsafe-inline' when layering a content security policy on top of old code. When considering 'unsafe-inline', authors are encouraged to consider nonces (or hashes) instead.

7.2. Nonce Stealing

Dangling markup attacks such as those discussed in [FILEDESCRIPTOR-2015] can be used to repurpose a page’s legitimate nonces for injections. For example, given an injection point before a script element:

<p>Hello, [INJECTION POINT]</p>
<script nonce=abc src=/good.js></script>

If an attacker injects the string "<script src='https://evil.com/evil.js' ", then the browser will receive the following:

<p>Hello, <script src='https://evil.com/evil.js' </p>
<script nonce=abc src=/good.js></script>

It will then parse that code, ending up with a script element with a src attribute pointing to a malicious payload, an attribute named </p>, an attribute named "<script", a nonce attribute, and a second src attribute which is helpfully discarded as duplicate by the parser.

The §6.6.2.1 Is element nonceable? algorithm attempts to mitigate this specific attack by walking through script element attributes, looking for the string "<script" or "<style" in their names or values.

7.3. Nonce Retargeting

Nonces bypass host-source expressions, enabling developers to load code from any origin. This, generally, is fine, and desirable from the developer’s perspective. However, if an attacker can inject a base element, then an otherwise safe page can be subverted when relative URLs are resolved. That is, on https://example.com/ the following code will load https://example.com/good.js:

<script nonce=abc src=/good.js></script>

However, the following will load https://evil.com/good.js:

<base href="https://evil.com">
<script nonce=abc src=/good.js></script>

To mitigate this risk, it is advisable to set an explicit base element on every page, or to limit the ability of an attacker to inject their own base element by setting a base-uri directive in your page’s policy. For example, base-uri 'none'.

7.4. CSS Parsing

The style-src directive restricts the locations from which the protected resource can load styles. However, if the user agent uses a lax CSS parsing algorithm, an attacker might be able to trick the user agent into accepting malicious "stylesheets" hosted by an otherwise trustworthy origin.

These attacks are similar to the CSS cross-origin data leakage attack described by Chris Evans in 2009 [CSS-ABUSE]. User agents SHOULD defend against both attacks using the same mechanism: stricter CSS parsing rules for style sheets with improper MIME types.

7.5. Violation Reports

The violation reporting mechanism in this document has been designed to mitigate the risk that a malicious web site could use violation reports to probe the behavior of other servers. For example, consider a malicious web site that allows https://example.com as a source of images. If the malicious site attempts to load https://example.com/login as an image, and the example.com server redirects to an identity provider (e.g. identityprovider.example.net), CSP will block the request. If violation reports contained the full blocked URL, the violation report might contain sensitive information contained in the redirected URL, such as session identifiers or purported identities. For this reason, the user agent includes only the URL of the original request, not the redirect target.

Note also that violation reports should be considered attacker-controlled data. Developers who wish to collect violation reports in a dashboard or similar service should be careful to properly escape their content before rendering it (and should probably themselves use CSP to further mitigate the risk of injection). This is especially true for the "script-sample" property of violation reports, and the sample property of SecurityPolicyViolationEvent, which are both completely attacker-controlled strings.

7.6. Paths and Redirects

Directly loading https://example.org/not-path would fail, as it doesn’t match the policy.
Directly loading https://example.com/redirector would pass, as it matches example.com.
Assuming that https://example.com/redirector delivered a redirect response pointing to https://example.org/not-path, the load would succeed, as the initial URL matches example.com, and the redirect target matches example.org/path if we ignore its path component.

This restriction reduces the granularity of a document’s policy when redirects are in play, a necessary compromise to avoid brute-forced information leaks of this type.

The relatively long thread "Remove paths from CSP?" from public-webappsec@w3.org has more detailed discussion around alternate proposals.

7.7. Secure Upgrades

To mitigate one variant of history-scanning attacks like Yan Zhu’s Sniffly, CSP will not allow pages to lock themselves into insecure URLs via policies like script-src http://example.com. As described in §6.6.1.7 scheme-part matching, the scheme portion of a source expression will always allow upgrading to a secure variant.

7.8. CSP Inheriting to avoid bypasses

As described in §4.2.1 Initialize a Document's CSP list and §4.2.2 Initialize a global object’s CSP list, documents loaded from local schemes will inherit a copy of the policies in the CSP list of the embedding document or opener browsing context. The goal is to ensure that a page can’t bypass its policy by embedding a frame or opening a new window containg content that is entirely under its control (srcdoc documents, blob: or data: URLs, about:blank documents that can be manipulated via document.write(), etc).

If this would not happen a page could execute inline scripts even without unsafe-inline in the page’s execution context by simply embedding a srcdoc iframe.

<iframe srcdoc="<script>alert(1);</script>"></iframe>

Note that we create a copy of the CSP list which means that the new Document's CSP list is a snapshot of the relevant policies at its creation time. Modifications in the CSP list of the new Document won’t affect the embedding document or opener browsing context’s CSP list or vice-versa.

In the example below the image inside the iframe will not load because it is blocked by the policy in the meta tag of the iframe. The image outside the iframe will load (assuming the main page policy does not block it) since the policy inserted in the iframe will not affect it.

<iframe srcdoc='<meta http-equiv="Content-Security-Policy" content="img-src example.com;">
                   <img src="not-example.com/image">'></iframe>

<img src="not-example.com/image">

8. Authoring Considerations

8.1. The effect of multiple policies

This section is not normative.

Content-Security-Policy: default-src 'self' http://example.com http://example.net;
                         connect-src 'none';
Content-Security-Policy: connect-src http://example.com/;
                         script-src http://example.com/

Is a connection to example.com allowed or not? The short answer is that the connection is not allowed. Enforcing both policies means that a potential connection would have to pass through both unscathed. Even though the second policy would allow this connection, the first policy contains connect-src 'none', so its enforcement blocks the connection. The impact is that adding additional policies to the list of policies to enforce can only further restrict the capabilities of the protected resource.

8.2. Usage of "`'strict-dynamic'`"

Host- and path-based policies are tough to get right, especially on sprawling origins like CDNs. The solutions to Cure53’s H5SC Minichallenge 3: "Sh*t, it’s CSP!" [H5SC3] are good examples of the kinds of bypasses which such policies can enable, and though CSP is capable of mitigating these bypasses via exhaustive declaration of specific resources, those lists end up being brittle, awkward, and difficult to implement and maintain.

The "'strict-dynamic'" source expression aims to make Content Security Policy simpler to deploy for existing applications who have a high degree of confidence in the scripts they load directly, but low confidence in their ability to provide a reasonable list of resources to load up front.

If present in a script-src or default-src directive, it has two main effects:

host-source and scheme-source expressions, as well as the "'unsafe-inline'" and "'self' keyword-sources will be ignored when loading script.

hash-source and nonce-source expressions will be honored.
Script requests which are triggered by non-"parser-inserted" script elements are allowed.

The first change allows you to deploy "'strict-dynamic' in a backwards compatible way, without requiring user-agent sniffing: the policy 'unsafe-inline' https: 'nonce-abcdefg' 'strict-dynamic' will act like 'unsafe-inline' https: in browsers that support CSP1, https: 'nonce-DhcnhD3khTMePgXwdayK9BsMqXjhguVV' in browsers that support CSP2, and 'nonce-DhcnhD3khTMePgXwdayK9BsMqXjhguVV' 'strict-dynamic' in browsers that support CSP3.

The second allows scripts which are given access to the page via nonces or hashes to bring in their dependencies without adding them explicitly to the page’s policy.

Suppose MegaCorp, Inc. deploys the following policy:

Content-Security-Policy: script-src 'nonce-DhcnhD3khTMePgXwdayK9BsMqXjhguVV' 'strict-dynamic'

And serves the following HTML with that policy active:

...
<script src="https://cdn.example.com/script.js" nonce="DhcnhD3khTMePgXwdayK9BsMqXjhguVV" ></script>
...

This will generate a request for https://cdn.example.com/script.js, which will not be blocked because of the matching nonce attribute.

If script.js contains the following code:

var s = document.createElement('script');
s.src = 'https://othercdn.not-example.net/dependency.js';
document.head.appendChild('s');

document.write('<scr' + 'ipt src='/sadness.js'></scr' + 'ipt>');

dependency.js will load, as the script element created by createElement() is not "parser-inserted".

sadness.js will not load, however, as document.write() produces script elements which are "parser-inserted".

8.3. Usage of "`'unsafe-hashed-attributes'`"

This section is not normative.

Work in progress. <https://github.com/w3c/webappsec-csp/issues/13>

Legacy websites and websites with legacy dependencies might find it difficult to entirely externalize event handlers. These sites could enable such handlers by allowing 'unsafe-inline', but that’s a big hammer with a lot of associated risk (and cannot be used in conjunction with nonces or hashes).

The "'unsafe-hashed-attributes'" source expression aims to make CSP deployment simpler and safer in these situations by allowing developers to enable specific handlers via hashes.

MegaCorp, Inc. can’t quite get rid of the following HTML on anything resembling a reasonable schedule:

<button id="action" onclick="doSubmit()">

Rather than reducing security by specifying "'unsafe-inline'", they decide to use "'unsafe-hashed-attributes'" along with a hash source expression, as follows:

Content-Security-Policy:  script-src 'unsafe-hashed-attributes' 'sha256-jzgBGA4UWFFmpOBq0JpdsySukE1FrEN5bUpoK8Z29fY='

The capabilities 'unsafe-hashed-attributes' provides is useful for legacy sites, but should be avoided for modern sites. In particular, note that hashes allow a particular script to execute, but do not ensure that it executes in the way a developer intends. If an interesting capability is exposed as an inline event handler (say <a onclick="transferAllMyMoney()">Transfer</a>), then that script becomes available for an attacker to inject as <script>transferAllMyMoney()</script>. Developers should be careful to balance the risk of allowing specific scripts to execute against the deployment advantages that allowing inline event handlers might provide.

8.4. Allowing external JavaScript via hashes

In [CSP2], hash source expressions could only match inlined script, but now that Subresource Integrity is widely deployed, we can expand the scope to enable externalized JavaScript as well.

If multiple sets of integrity metadata are specified for a script, the request will match a policy’s hash-sources if and only if each item in a script's integrity metadata matches the policy.

MegaCorp, Inc. wishes to allow two specific scripts on a page in a way that ensures that the content matches their expectations. They do so by setting the following policy:

Content-Security-Policy: script-src 'sha256-abc123' 'sha512-321cba'

In the presence of that policy, the following script elements would be allowed to execute because they contain only integrity metadata that matches the policy:

<script integrity="sha256-abc123" ...></script>
<script integrity="sha512-321cba" ...></script>
<script integrity="sha256-abc123 sha512-321cba" ...></script>

While the following script elements would not execute because they contain valid metadata that does not match the policy (even though other metadata does match):

<script integrity="sha384-xyz789" ...></script>
<script integrity="sha384-xyz789 sha512-321cba" ...></script>
<script integrity="sha256-abc123 sha384-xyz789 sha512-321cba" ...></script>

Metadata that is not recognized (either because it’s entirely invalid, or because it specifies a not-yet-supported hashing algorithm) does not affect the behavior described here. That is, the following elements would be allowed to execute in the presence of the above policy, as the additional metadata is invalid and therefore wouldn’t allow a script whose content wasn’t listed explicitly in the policy to execute:

<script integrity="sha256-abc123 sha1024-abcd" ...></script>
<script integrity="sha512-321cba entirely-invalid" ...></script>
<script integrity="sha256-abc123 not-a-hash-at-all sha512-321cba" ...></script>

9. Implementation Considerations

9.1. Vendor-specific Extensions and Addons

Policy enforced on a resource SHOULD NOT interfere with the operation of user-agent features like addons, extensions, or bookmarklets. These kinds of features generally advance the user’s priority over page authors, as espoused in [HTML-DESIGN].

Moreover, applying CSP to these kinds of features produces a substantial amount of noise in violation reports, significantly reducing their value to developers.

Chrome, for example, excludes the chrome-extension: scheme from CSP checks, and does some work to ensure that extension-driven injections are allowed, regardless of a page’s policy.

10. IANA Considerations

10.1. Directive Registry

The Content Security Policy Directive registry should be updated with the following directives and references [RFC7762]:

base-uri: This document (see §6.2.1 base-uri)
child-src: This document (see §6.1.1 child-src)
connect-src: This document (see §6.1.2 connect-src)
default-src: This document (see §6.1.3 default-src)
disown-opener: This document (see §6.2.4 disown-opener)
font-src: This document (see §6.1.4 font-src)
form-action: This document (see §6.3.1 form-action)
frame-ancestors: This document (see §6.3.2 frame-ancestors)
frame-src: This document (see §6.1.5 frame-src)
img-src: This document (see §6.1.6 img-src)
manifest-src: This document (see §6.1.7 manifest-src)
media-src: This document (see §6.1.8 media-src)
object-src: This document (see §6.1.9 object-src)
plugin-types: This document (see §6.2.2 plugin-types)
report-uri: This document (see §6.4.1 report-uri)
report-to: This document (see §6.4.2 report-to)
sandbox: This document (see §6.2.3 sandbox)
script-src: This document (see §6.1.10 script-src)
style-src: This document (see §6.1.11 style-src)
worker-src: This document (see §6.1.12 worker-src)

10.2. Headers

The permanent message header field registry should be updated with the following registrations: [RFC3864]

10.2.1. Content-Security-Policy

Header field name: Content-Security-Policy
Applicable protocol: http
Status: standard
Author/Change controller: W3C
Specification document: This specification (See §3.1 The Content-Security-Policy HTTP Response Header Field)

10.2.2. Content-Security-Policy-Report-Only

Header field name: Content-Security-Policy-Report-Only
Applicable protocol: http
Status: standard
Author/Change controller: W3C
Specification document: This specification (See §3.2 The Content-Security-Policy-Report-Only HTTP Response Header Field)

11. Acknowledgements

Lots of people are awesome. For instance:

Mario and all of Cure53.
Artur Janc, Michele Spagnuolo, Lukas Weichselbaum, Jochen Eisinger, and the rest of Google’s CSP Cabal.

Conformance

Document conventions

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:

Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:

Conformant Algorithms

Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and abort these steps") are to be interpreted with the meaning of the key word ("must", "should", "may", etc) used in introducing the algorithm.

Conformance requirements phrased as algorithms or specific steps can be implemented in any manner, so long as the end result is equivalent. In particular, the algorithms defined in this specification are intended to be easy to understand and are not intended to be performant. Implementers are encouraged to optimize.

Index

Terms defined by this specification

Terms defined by reference

References

Normative References

Informative References

IDL Index

Issues Index

Content Security Policy: API

Content Security Policy: Cookie Controls

Abstract

Status of this document

Conformance

Document conventions

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words "for example" or are set apart from the normative text with class="example", like this:

Informative notes begin with the word "Note" and are set apart from the normative text with class="note", like this:

Conformant Algorithms

Index

Terms defined by this specification

Terms defined by reference

References

Normative References

Informative References

Issues Index

Content Security Policy: Document Features

Abstract

This document establishes an Internet Assigned Number Authority (IANA) registry for Content Security Policy directives. It populates the registry with the directives defined in the CSP specification.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

1. Introduction

The Content Security Policy specification [CSP] defines a mechanism by which web developers can control the resources which a particular page can fetch or execute, as well as a number of security-relevant policy decisions.

The policy language specified in that document consists of an extensible set of “directives”, each of which controls a specific resource type or policy decision. This specification establishes a registry to ensure that extensions to CSP are listed and standardized.

2. Terminology

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119].

3. Use of the Registry

Content Security Policy directives MUST be documented in a readily available public specification in order to be registered by IANA. This documentation MUST fully explain the syntax, intended usage, and semantics of the directive. The intent of this requirement is to assure interoperable independent implementations, and to prevent accidental namespace collisions between implementations of dissimilar features.

Documents defining new Content Security Policy directives MUST register them with IANA, as described in Section 4. The IANA registration policy for such parameters is “Specification Required, Designated Expert”, and is further discussed in Section 4.2.

4. IANA Considerations

This specification creates a new IANA registry named “Content Security Policy directives”.

4.1. Content Security Policy directives Registry

New Content Security Policy directives, and updates to existing directives, MUST be registered with IANA.

When registering a new Content Security Policy directive, the following information MUST be provided:

Directive Name	Reference
base-uri	[CSP]
child-src	[CSP]
connect-src	[CSP]
default-src	[CSP]
font-src	[CSP]
form-action	[CSP]
frame-ancestors	[CSP]
frame-src	[CSP]
img-src	[CSP]
media-src	[CSP]
object-src	[CSP]
plugin-types	[CSP]
report-uri	[CSP]
sandbox	[CSP]
script-src	[CSP]
style-src	[CSP]

4.2. Registration Policy for Content Security Policy directives

As per the terminology in [RFC5226] and actions accorded to such a role, the registration policy for Content Security Policy directives is “Specification Required, Designated Expert” (the former implies the latter).

The Designated Expert, when deliberating on whether to include a new directive in the registry, MAY use the criteria provided below to reach a decision. These are not an exhaustive list, but representative of the issues to consider when rendering an equitable decision):

5. Security Considerations

The registry in this document does not in itself have security implications. The directives specified, however, certainly do. The documents referenced when registering new directives MUST contain detailed security and privacy considerations sections, and SHOULD contain usage information which informs web developers as to the directive’s expected implementation.

6. References

6.1. Normative References

6.2. Informative References

Appendix A. Acknowledgements

I’ve cargo-culted this document from [RFC5341], so thank you to Cullen Jennings and Vijay K. Gurbani for giving me a reasonable template to work within.

Directive Name	Reference
base-uri	[CSP]
child-src	[CSP]
connect-src	[CSP]
default-src	[CSP]
font-src	[CSP]
form-action	[CSP]
frame-ancestors	[CSP]
frame-src	[CSP]
img-src	[CSP]
media-src	[CSP]
object-src	[CSP]
plugin-types	[CSP]
report-uri	[CSP]
sandbox	[CSP]
script-src	[CSP]
style-src	[CSP]

Directive Name	Reference
base-uri	[CSP]
child-src	[CSP]
connect-src	[CSP]
default-src	[CSP]
font-src	[CSP]
form-action	[CSP]
frame-ancestors	[CSP]
frame-src	[CSP]
img-src	[CSP]
media-src	[CSP]
object-src	[CSP]
plugin-types	[CSP]
report-uri	[CSP]
sandbox	[CSP]
script-src	[CSP]
style-src	[CSP]

Directive Name	Reference
base-uri	[CSP]
child-src	[CSP]
connect-src	[CSP]
default-src	[CSP]
font-src	[CSP]
form-action	[CSP]
frame-ancestors	[CSP]
frame-src	[CSP]
img-src	[CSP]
media-src	[CSP]
object-src	[CSP]
plugin-types	[CSP]
report-uri	[CSP]
sandbox	[CSP]
script-src	[CSP]
style-src	[CSP]

Directive Name	Reference
base-uri	[CSP]
child-src	[CSP]
connect-src	[CSP]
default-src	[CSP]
font-src	[CSP]
form-action	[CSP]
frame-ancestors	[CSP]
frame-src	[CSP]
img-src	[CSP]
media-src	[CSP]
object-src	[CSP]
plugin-types	[CSP]
report-uri	[CSP]
sandbox	[CSP]
script-src	[CSP]
style-src	[CSP]

This document defines a policy language used to declare a set of content restrictions for a web resource, and a mechanism for transmitting the policy from a server to a client where the policy is enforced.

[CSP]	West, M. and D. Veditz, "Content Security Policy", n.d..
[RFC2119]	Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC5226]	Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008.

[CSP]	West, M. and D. Veditz, "Content Security Policy", n.d..
[RFC2119]	Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5226]	Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008.
[RFC5234]	Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.

[CSP]	West, M. and D. Veditz, "Content Security Policy", n.d..
[RFC2119]	Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5226]	Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008.
[RFC5234]	Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.

[CSP]	West, M. and D. Veditz, "Content Security Policy", n.d..
[RFC5226]	Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008.
[RFC5234]	Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.

[CSP]	West, M., Barth, A. and D. Veditz, "Content Security Policy Level 2", n.d..
[RFC5226]	Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008.
[RFC5234]	Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008.

Content Security Policy Level 2

Introduction

Changes from Level 1

Key Concepts and Terminology

Terms defined by this specification

Terms defined by reference

Relevant Concepts from HTML

Grammatical Concepts

Policy Delivery

Content-Security-Policy Header Field

Content-Security-Policy-Report-Only Header Field

HTML <{meta}> Element

Enforcing multiple policies

Policy applicability

Syntax and Algorithms

Policy Syntax

Parsing Policies

Source List Syntax

Parsing Source Lists

Matching Source Expressions

Security Considerations for GUID URL schemes

Path Matching

Paths and Redirects

The nonce attribute

Valid Nonces

Valid Hashes

Media Type List Syntax

Parsing

Matching

Reporting

Processing Model

Workers

srcdoc iframes

Script Interfaces

SecurityPolicyViolationEvent Interface

SecurityPolicyViolationEventInit Interface

Firing Violation Events

Directives

base-uri

child-src

Nested Browsing Contexts

Workers

connect-src

Usage

default-src

Usage

font-src

form-action

frame-ancestors

Relation to X-Frame-Options

Multiple Host Source Values

frame-src

img-src

media-src

object-src

plugin-types

Usage

Predeclaration of expected media types

report-uri

sandbox

Sandboxing and Workers

Usage

script-src

Nonce usage for script elements

Hash usage for script elements

style-src

Nonce usage for style elements

Hash usage for style elements

Examples

Sample Policy Definitions

Sample Violation Report

Security Considerations

Cascading Style Sheet (CSS) Parsing

Redirect Information Leakage

Implementation Considerations

Processing Complications

IANA Considerations