Content Security Policy Level 3

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 child-src if not present (which likewise defers to script-src and eventually default-src).
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-hashes' source expression will now allow event handlers, style attributes and javascript: navigation targets to match hashes. Details in § 8.3 Usage of "'unsafe-hashes'".
The source expression matching has been changed to require explicit presence of any non-HTTP(S) scheme, rather than local scheme, unless that non-HTTP(S) scheme is the same as the scheme of protected resource, as described in § 6.7.2.8 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.
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 5.6.1 of [RFC9110], with the modification that OWS is replaced with optional-ascii-whitespace. That is, the #rule used in this document is defined as:

1#element => element *( optional-ascii-whitespace "," optional-ascii-whitespace element )

and for n >= 1 and m > 1:

<n>#<m>element => element <n-1>*<m-1>( optional-ascii-whitespace "," optional-ascii-whitespace element )

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

The following definitions are used to improve readability of other definitions in this document.

optional-ascii-whitespace = *( %x09 / %x0A / %x0C / %x0D / %x20 )
required-ascii-whitespace = 1*( %x09 / %x0A / %x0C / %x0D / %x20 )
; These productions match the definition of ASCII whitespace from the INFRA standard.

2.2. Policies

A policy defines allowed and restricted behaviors, and may be applied to a Document, WorkerGlobalScope, or WorkletGlobalScope.

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. A CSP list is a struct consisting of policies (a list of policies) and a self-origin (an origin which is used when matching the 'self' keyword).

Note: This is needed to facilitate the 'self' checks of local scheme documents/workers that have inherited their policy but have an opaque origin. Most of the time this will simply be the environment settings object’s origin.

A CSP list contains a header-delivered Content Security Policy if its policies contain 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 *( optional-ascii-whitespace ";" [ optional-ascii-whitespace serialized-directive ] )

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 the one defined in section 5.6.1 of RFC 9110
                    ; but it incorporates the modifications specified
                    ; in section 2.1 of this document.

2.2.1. Parse a serialized CSP

To parse a serialized CSP, given a byte sequence or string 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.

If serialized is a byte sequence, then set serialized to be the result of isomorphic decoding serialized.
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, or if token is not an ASCII string, continue.
3. Let directive name be the result of collecting a sequence of code points from token which are not ASCII whitespace.
4. Set directive name to be the result of running ASCII lowercase on directive name.
  
  Note: Directive names are case-insensitive, that is: script-SRC 'none' and ScRiPt-sRc 'none' are equivalent.
5. If policy’s directive set contains a directive whose name is directive name, continue.
  
  Note: In this case, the user agent SHOULD notify developers that a duplicate directive was ignored. A console warning might be appropriate, for example.
6. Let directive value be the result of splitting token on ASCII whitespace.
7. Let directive be a new directive whose name is directive name, and value is directive value.
8. Append directive to policy’s directive set.
Return policy.

2.2.2. Parse `response`’s Content Security Policies

To parse a response’s Content Security Policies given a response response, execute the following steps.

This algorithm returns a CSP list. If the policies cannot be parsed, the returned list will have empty policies.

Let policies be an empty list.
For each token returned by extracting header list values given Content-Security-Policy and response’s header list:
1. Let policy be the result of parsing token, with a source of "header", and a disposition of "enforce".
2. If policy’s directive set is not empty, append policy to policies.
For each token returned by extracting header list values given Content-Security-Policy-Report-Only and response’s header list:
1. Let policy be the result of parsing token, with a source of "header", and a disposition of "report".
2. If policy’s directive set is not empty, append policy to policies.
Return a CSP list whose policies is policies and self-origin is response’s url’s origin.

Note: When parsing a response’s Content Security Policies, if the resulting policies end up containing at least one item, user agents can hold a flag on policies and use it to optimize away the contains a header-delivered Content Security Policy algorithm.

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 [ required-ascii-whitespace directive-value ]
directive-name       = 1*( ALPHA / DIGIT / "-" )
directive-value      = *( required-ascii-whitespace / ( %x21-%x2B / %x2D-%x3A / %x3C-%x7E ) )
                       ; Directive values may contain whitespace and VCHAR characters,
                       ; excluding ";" and ",". The second half of the definition
                       ; above represents all VCHAR characters (%x21-%x7E)
                       ; without ";" and "," (%x3B and %x2C respectively)

; 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, a policy, and an origin as an argument, and is executed during § 4.1.2 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, a policy and an origin as arguments, and is executed during § 4.1.3 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, a policy, and a source string as arguments, and is executed during § 4.2.3 Should element’s inline type behavior be blocked by Content Security Policy? and during § 4.2.4 Should navigation request of type be blocked by Content Security Policy? for javascript: requests. This algorithm returns "Allowed" unless otherwise specified.
An initialization, which takes a Document or global object and a policy as arguments. This algorithm is executed during § 4.2.1 Run CSP initialization for a Document and § 4.2.6 Run CSP initialization for a global object. Unless otherwise specified, it has no effect and it returns "Allowed".
A pre-navigation check, which takes a request, a navigation type string ("form-submission" or "other"), a policy and an origin as arguments, and is executed during § 4.2.4 Should navigation request of type be blocked by Content Security Policy?. It returns "Allowed" unless otherwise specified.
A navigation response check, which takes a request, a navigation type string ("form-submission" or "other"), a response, a navigable, a check type string ("source" or "response"), a policy, and an origin as arguments, and is executed during § 4.2.5 Should navigation response to navigation request of type in target be blocked by Content Security Policy?. It returns "Allowed" unless otherwise specified.
A webrtc pre-connect check, which takes a policy, and is executed during § 4.3.1 Should RTC connections be blocked for global?. It returns "Allowed" unless otherwise specified.

2.3.1. Source Lists

Many directives' value 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 *( required-ascii-whitespace 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 (but not including ";" or ",")
              ; path-absolute is defined in section 3.3 of RFC 3986.

; Keywords:
keyword-source = "'self'" / "'unsafe-inline'" / "'unsafe-eval'"
                 / "'strict-dynamic'" / "'unsafe-hashes'"
                 / "'report-sample'" / "'unsafe-allow-redirects'"
                 / "'wasm-unsafe-eval'" / "'trusted-types-eval'"
                 / "'report-sha256'" / "'report-sha384'"
                 / "'report-sha512'" / "'unsafe-webtransport-hashes'"

ISSUE: Bikeshed unsafe-allow-redirects.

; 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.7.2.7 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", "wasm-eval", "trusted-types-policy", "trusted-types-sink" or a URL. It represents the resource which violated the policy.

Note: The value null for a violation’s resource is only allowed while the violation is being populated. By the time the violation is reported and its resource is used for obtaining the blocked URI, the violation’s resource should be populated with a URL or one of the allowed strings.

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`, and `policy`.

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

Let directive be the result of executing § 6.8.1 Get the effective directive for request on request.
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
                    ; The '#' rule is the one defined in section 5.6.1 of RFC 9110
                    ; but it incorporates the modifications specified
                    ; in section 2.1 of this document.

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.

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
                    ; The '#' rule is the one defined in section 5.6.1 of RFC 9110
                    ; but it incorporates the modifications specified
                    ; in section 2.1 of this document.

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.

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: 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 § 8.1 The effect of multiple policies.

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.2 Should request be blocked by Content Security Policy? is called as part of step 2.4 of the 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.3 Should response to request be blocked by Content Security Policy? is called as part of step 11 of the Main Fetch algorithm. This allows directives' post-request checks to be executed on the response delivered from the network or from a Service Worker.

4.1.1. Report Content Security Policy violations for `request`

Given a request request, this algorithm reports violations based on policy container’s CSP list "report only" policies.

Let CSP list be request’s policy container’s CSP list.
For each policy of CSP list’s policies:
1. If policy’s disposition is "enforce", then skip to the next policy.
2. Let violates be the result of executing § 6.7.2.1 Does request violate policy? on request, policy, and CSP list’s self-origin.
3. If violates is not "Does Not Violate", then execute § 5.5 Report a violation on the result of executing § 2.4.2 Create a violation object for request, and policy. on request, and policy.

4.1.2. 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 policy container’s CSP list.

Let CSP list be request’s policy container’s CSP list.
Let result be "Allowed".
For each policy of CSP list’s policies:
1. If policy’s disposition is "report", then skip to the next policy.
2. Let violates be the result of executing § 6.7.2.1 Does request violate policy? on request, policy, and CSP list’s self-origin.
3. If violates is not "Does Not Violate", then:
  1. Execute § 5.5 Report a violation on the result of executing § 2.4.2 Create a violation object for request, and policy. on request, and policy.
  2. Set result to "Blocked".
Return result.

4.1.3. 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 policy container’s CSP list.

Let CSP list be request’s policy container’s CSP list.
Let result be "Allowed".
For each policy of CSP list’s policies:
1. For each directive of policy:
  1. If the result of executing directive’s post-request check on request, response, policy, and CSP list’s self-origin is "Blocked", then:
    1. Execute § 5.5 Report a violation on the result of executing § 2.4.2 Create a violation object for request, and policy. on request, and policy.
    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.
Return result.

4.1.4. Potentially report hash

Given a response response, a request request, a directive directive and a content security policy object policy, run the following steps:

Let algorithm be the empty string.
If directive’s value contains the expression "'report-sha256'", set algorithm to "sha256".
If directive’s value contains the expression "'report-sha384'", set algorithm to "sha384".
If directive’s value contains the expression "'report-sha512'", set algorithm to "sha512".
If algorithm is the empty string, return.
Let hash be the empty string.
If response is CORS-same-origin, then:
1. Let h be the result of applying algorithm to bytes on response’s body and algorithm.
2. Let hash be the concatenation of algorithm, U+2D (-), and h.
Let global be the request’s client’s global object.
If global is not a Window, return.
Let stripped document URL to be the result of executing § 5.4 Strip URL for use in reports on global’s document’s URL.
If policy’s directive set does not contain a directive named "report-to", return.
Let report-to directive be a directive named "report-to" from policy’s directive set.
Let body be a csp hash report body with stripped document URL as its documentURL, request’s URL as its subresourceURL, hash as its hash, request’s destination as its destination, and "subresource" as its type.
Generate and queue a report with the following arguments:

context

settings object

type

"csp-hash"

destination

report-to directive’s value.

data

body

4.2. Integration with HTML

The policy container has 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 from the response by parsing response’s Content Security Policies or inherited following the rules of the policy container.
A global object’s CSP list is the result of executing § 4.2.2 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.1 Run CSP initialization for a Document is called during the create and initialize a new Document object algorithm.
§ 4.2.3 Should element’s inline type behavior be blocked by Content Security Policy? is called during the prepare the script element 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.3 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.
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 WHATWG’s HTML. [whatwg/html Issue #968]
§ 6.3.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.
§ 4.2.4 Should navigation request of type be blocked by Content Security Policy? is called during the create navigation params by fetching algorithm, and § 4.2.5 Should navigation response to navigation request of type in target be blocked by Content Security Policy? is called during the attempt to populate the history entry’s document algorithm to apply directive’s navigation checks, as well as inline checks for navigations to javascript: URLs.
§ 4.2.6 Run CSP initialization for a global object is called during the run a worker algorithm.
The sandbox directive is used to populate the CSP-derived sandboxing flags.

4.2.1. Run `CSP` initialization for a `Document`

Given a Document document, the user agent performs the following steps in order to initialize CSP for document:

For each policy of document’s policy container’s CSP list:
1. For each directive of policy:
  1. Execute directive’s initialization algorithm on document and policy, and assert: its returned value is "Allowed".

4.2.2. Retrieve the CSP list of an `object`

To obtain object’s CSP list:

If object is a Document return object’s policy container’s CSP list.
If object is a Window or a WorkerGlobalScope or a WorkletGlobalScope, return environment settings object’s policy container’s CSP list.
Return null.

4.2.3. 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 of element’s Document’s global object’s CSP list’s policies:
1. For each directive of policy’s directive set:
  1. If directive’s inline check returns "Allowed" when executed upon element, type, policy and source, skip to the next directive.
  2. Let directive-name be the result of executing § 6.8.2 Get the effective directive for inline checks on type.
  3. 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 directive-name.
  4. Set violation’s resource to "inline".
  5. Set violation’s element to element.
  6. If directive’s value contains the expression "'report-sample'", then set violation’s sample to the substring of source containing its first 40 characters.
  7. Execute § 5.5 Report a violation on violation.
  8. If policy’s disposition is "enforce", then set result to "Blocked".
Return result.

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

Let result be "Allowed".
Let CSP list be navigation request’s policy container’s CSP list’s policies.
For each policy of CSP list’s policies:
1. For each directive of policy:
  1. If directive’s pre-navigation check returns "Allowed" when executed upon navigation request, type, policy, and CSP list’s self-origin 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 navigation request’s client’s global object, policy, and directive’s name.
  3. Set violation’s resource to navigation request’s URL.
  4. Execute § 5.5 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 current URL’s scheme is javascript:
1. For each policy of navigation request’s policy container’s CSP list’s policies:
  1. For each directive of policy:
    1. Let directive-name be the result of executing § 6.8.2 Get the effective directive for inline checks on "navigation".
    2. If directive’s inline check returns "Allowed" when executed upon null, "navigation", policy, and navigation request’s current URL, skip to the next directive.
    3. Otherwise, let violation be the result of executing § 2.4.1 Create a violation object for global, policy, and directive on navigation request’s client’s global object, policy, and directive-name.
    4. Set violation’s resource to "inline".
    5. Execute § 5.5 Report a violation on violation.
    6. If policy’s disposition is "enforce", then set result to "Blocked".
Return result.

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

Let result be "Allowed".
For each policy of response CSP list’s policies:

Note: Some directives (like frame-ancestors) allow a response’s Content Security Policy to act on the navigation.
1. For each directive of policy:
  1. If directive’s navigation response check returns "Allowed" when executed upon navigation request, type, navigation response, target, "response", policy, and response CSP list’s self-origin, 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.5 Report a violation on violation.
  5. If policy’s disposition is "enforce", then set result to "Blocked".
For each policy of navigation request’s policy container’s CSP list’s policies:

Note: Some directives in the navigation request’s context (like frame-ancestors) need the response before acting on the navigation.
1. For each directive of policy:
  1. If directive’s navigation response check returns "Allowed" when executed upon navigation request, type, navigation response, target, "source", policy, and response CSP list’s self-origin, 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 navigation request’s client’s global object, policy, and directive’s name.
  3. Set violation’s resource to navigation request’s URL.
  4. Execute § 5.5 Report a violation on violation.
  5. If policy’s disposition is "enforce", then set result to "Blocked".
Return result.

4.2.6. Run `CSP` initialization for a global object

Given a global object global, the user agent performs the following steps in order to initialize CSP for global. This algorithm returns "Allowed" if global is allowed, and "Blocked" otherwise:

Let result be "Allowed".
For each policy of global’s CSP list’s policies:
1. For each directive of policy:
  1. Execute directive’s initialization algorithm on global and policy. If its returned value is "Blocked", then set result to "Blocked".
Return result.

4.3. Integration with WebRTC

The administratively-prohibited algorithm calls § 4.3.1 Should RTC connections be blocked for global? when invoked, and prohibits all candidates if it returns "Blocked".

4.3.1. Should RTC connections be blocked for `global`?

Given a global object global, this algorithm returns "Blocked" if the active policy for global blocks RTC connections, and "Allowed" otherwise:

Let result be "Allowed".
For each policy of global’s CSP list’s policies:
1. For each directive of policy:
  1. If directive’s webrtc pre-connect check returns "Allowed" when executed upon policy, continue.
  2. Otherwise, let violation be the result of executing § 2.4.1 Create a violation object for global, policy, and directive on global, policy, and directive’s name.
  3. Set violation’s resource to null.
  4. Execute § 5.5 Report a violation on violation.
  5. If policy’s disposition is "enforce", then set result to "Blocked".
Return result.

4.4. 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 which examines the relevant CSP list to determine whether such compilation ought to be blocked.

4.4.1. EnsureCSPDoesNotBlockStringCompilation(`realm`, `parameterStrings`, `bodyString`, `codeString`, `compilationType`, `parameterArgs`, `bodyArg`)

Given a realm realm, a list of strings parameterStrings, a string bodyString, a string codeString, an enum (compilationType), a list of ECMAScript language values (parameterArgs), and an ECMAScript language value (bodyArg), this algorithm returns normally if string compilation is allowed, and throws an "EvalError" if not:

Let sourceString be codeString.
If compilationType is not "TIMER", then:
1. Let compilationSink be "Function" if compilationType is "FUNCTION", and "eval" otherwise.
2. Let isTrusted be true if bodyArg implements TrustedScript, and false otherwise.
3. If isTrusted is true then:
  1. If bodyString is not equal to bodyArg’s data, set isTrusted to false.
4. If isTrusted is true, then:
  1. Assert: parameterArgs’ [list/size=] is equal to [parameterStrings]' size.
  2. For each index of the range 0 to |parameterArgs]' [list/size=]:
    1. Let arg be parameterArgs[index].
    2. If arg implements TrustedScript, then:
      1. if parameterStrings[index] is not equal to arg’s data, set isTrusted to false.
    3. Otherwise, set isTrusted to false.
5. If isTrusted is false, then:
  1. Set sourceString to the result of executing the get trusted type compliant string algorithm, with TrustedScript, realm, codeString, compilationSink, and 'script'.
  2. If the algorithm throws an error, throw an EvalError.
  3. If sourceString is not equal to codeString, throw an EvalError.
Let result be "Allowed".
Let global be realm’s global object.
For each policy of global’s CSP list’s policies:
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 not null:
  1. Let trustedTypesRequired be the result of executing does sink type require trusted types?, with realm, 'script', and false.
  2. If trustedTypesRequired is true and source-list contains a source expression which is an ASCII case-insensitive match for the string "'trusted-types-eval'", then skip the following steps.
  3. If source-list contains a source expression which is an ASCII case-insensitive match for the string "'unsafe-eval'", then skip the following steps.
  4. 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".
  5. Set violation’s resource to "eval".
  6. If source-list contains the expression "'report-sample'", then set violation’s sample to the substring of sourceString containing its first 40 characters.
  7. Execute § 5.5 Report a violation on violation.
  8. If policy’s disposition is "enforce", then set result to "Blocked".
If result is "Blocked", throw an EvalError exception.

4.5. Integration with WebAssembly

WebAssembly defines the HostEnsureCanCompileWasmBytes() abstract operation which allows the host environment to block the compilation of WebAssembly sources into executable code. This document defines an implementation of this abstract operation which examines the relevant CSP list to determine whether such compilation ought to be blocked.

4.5.1. EnsureCSPDoesNotBlockWasmByteCompilation`realm`

Given a realm realm, this algorithm returns normally if compilation is allowed, and throws a WebAssembly.CompileError if not:

Let global be realm’s global object.
Let result be "Allowed".
For each policy of global’s CSP list’s policies:
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'", and does not contain a source expression which is an ASCII case-insensitive match for the string "'wasm-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 "wasm-eval".
  3. Execute § 5.5 Report a violation on violation.
  4. If policy’s disposition is "enforce", then set result to "Blocked".
If result is "Blocked", throw a WebAssembly.CompileError exception.

5. Reporting

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

csp violation reports have the report type "csp-violation".

csp violation reports are visible to ReportingObservers.

dictionary CSPViolationReportBody : ReportBody {
  USVString documentURL;
  USVString? referrer;
  USVString? blockedURL;
  DOMString effectiveDirective;
  DOMString originalPolicy;
  USVString? sourceFile;
  DOMString? sample;
  SecurityPolicyViolationEventDisposition disposition;
  unsigned short statusCode;
  unsigned long? lineNumber;
  unsigned long? columnNumber;
};

When a directive that impacts script-like destinations has a report-sha256, report-sha384 or report-sha512 value, and a request with a script-like destination is fetched, a csp hash report will be generated and sent out to a reporting endpoint associated with the policy.

csp hash reports have the report type "csp-hash".

csp hash reports are not visible to ReportingObservers.

A csp hash report body is a struct with the following fields: documentURL, subresourceURL, hash, destination, type.

When a document’s response contains the headers:

Reporting-Endpoints: hashes-endpoint="https://example.com/reports"
Content-Security-Policy: script-src 'self' 'report-sha256'; report-to hashes-endpoint

and the document loads the script "main.js", a report similar to the following one will be sent:

POST /reports HTTP/1.1
Host: example.com
...
Content-Type: application/reports+json

[{
  "type": "csp-hash",
  "age": 12,
  "url": "https://example.com/",
  "user_agent": "Mozilla/5.0 (X11; Linux i686; rv:132.0) Gecko/20100101 Firefox/132.0",
  "body": {
    "document_url": "https://example.com/",
    "subresource_url": "https://example.com/main.js",
    "hash": "sha256-85738f8f9a7f1b04b5329c590ebcb9e425925c6d0984089c43a022de4f19c281",
    "type": "subresource",
    "destination": "script"
  }
}]

5.1. Violation DOM Events

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

[Exposed=(Window,Worker)]
interface SecurityPolicyViolationEvent : Event {
    constructor(DOMString type, optional SecurityPolicyViolationEventInit eventInitDict = {});
    readonly    attribute USVString      documentURI;
    readonly    attribute USVString      referrer;
    readonly    attribute USVString      blockedURI;
    readonly    attribute DOMString      effectiveDirective;
    readonly    attribute DOMString      violatedDirective; // historical alias of effectiveDirective
    readonly    attribute DOMString      originalPolicy;
    readonly    attribute USVString      sourceFile;
    readonly    attribute DOMString      sample;
    readonly    attribute SecurityPolicyViolationEventDisposition      disposition;
    readonly    attribute unsigned short statusCode;
    readonly    attribute unsigned long  lineNumber;
    readonly    attribute unsigned long  columnNumber;
};

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

5.2. Obtain the `blockedURI` of a violation’s `resource`

Given a violation’s resource resource, this algorithm returns a string, to be used as the blocked URI field for violation reports.

Assert: resource is a URL or a string.
If resource is a URL, return the result of executing § 5.4 Strip URL for use in reports on resource.
Return resource.

5.3. 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 body be a map with its keys initialized as follows:

"document-uri"

The result of executing § 5.4 Strip URL for use in reports on violation’s url.

"referrer"

The result of executing § 5.4 Strip URL for use in reports on violation’s referrer.

"blocked-uri"

The result of executing § 5.2 Obtain the blockedURI of a violation’s resource on violation’s resource.

"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 body["source-file'] to the result of executing § 5.4 Strip URL for use in reports on violation’s source file.
2. Set body["line-number"] to violation’s line number.
3. Set body["column-number"] to violation’s column number.
Assert: If body["blocked-uri"] is not "inline", then body["sample"] is the empty string.
Return the result of serialize an infra value to JSON bytes given «[ "csp-report" → body ]».

5.4. Strip URL for use in reports

Given a URL url, this algorithm returns a string representing the URL for use in violation reports:

If url’s scheme is not an HTTP(S) scheme, then return url’s scheme.
Set url’s fragment to the empty string.
Set url’s username to the empty string.
Set url’s password to the empty string.
Return the result of executing the URL serializer on url.

5.5. 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 to violation’s global object.
  2. If target is a Window, set target to target’s associated Document.
3. If target implements EventTarget, fire an event named securitypolicyviolation that uses the SecurityPolicyViolationEvent interface at target with its attributes initialized as follows:
  
  documentURI
  
  The result of executing § 5.4 Strip URL for use in reports on violation’s url.
  
  referrer
  
  The result of executing § 5.4 Strip URL for use in reports on violation’s referrer.
  
  blockedURI
  
  The result of executing § 5.2 Obtain the blockedURI of a violation’s resource on violation’s resource.
  
  effectiveDirective
  
  violation’s effective directive
  
  violatedDirective
  
  violation’s effective directive
  
  originalPolicy
  
  The serialization of violation’s policy
  
  disposition
  
  violation’s disposition
  
  sourceFile
  
  The result of executing § 5.4 Strip URL for use in reports on violation’s source file, if violation’s source file is not null, or null otherwise.
  
  statusCode
  
  violation’s status
  
  lineNumber
  
  violation’s line number
  
  columnNumber
  
  violation’s column number
  
  sample
  
  violation’s sample
  
  bubbles
  
  true
  
  composed
  
  true
  
  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.
  
  Note: Both effectiveDirective and violatedDirective are the same value. This is intentional to maintain backwards compatibility.
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. For each token of directive’s value:
    1. Let endpoint be the result of executing the URL parser with token as the input, and violation’s url as the base URL.
    2. If endpoint is not a valid URL, skip the remaining substeps.
    3. Let request be a new request, initialized as follows:
      
      method
      
      "POST"
      
      url
      
      endpoint
      
      origin
      
      violation’s global object’s relevant settings object’s origin
      
      traversable for user prompts
      
      "no-traversable"
      
      client
      
      violation’s global object’s relevant settings object
      
      destination
      
      "report"
      
      initiator
      
      ""
      
      credentials mode
      
      "same-origin"
      
      keepalive
      
      "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.3 Obtain the deprecated serialization of violation on violation
      
      redirect mode
      
      "error"
      
      Note: request’s mode defaults to "no-cors"; the response is ignored entirely.
    4. 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 body be a new CSPViolationReportBody, initialized as follows:
    
    documentURL
    
    The result of executing § 5.4 Strip URL for use in reports on violation’s url.
    
    referrer
    
    The result of executing § 5.4 Strip URL for use in reports on violation’s referrer.
    
    blockedURL
    
    The result of executing § 5.2 Obtain the blockedURI of a violation’s resource on violation’s resource.
    
    effectiveDirective
    
    violation’s effective directive.
    
    originalPolicy
    
    The serialization of violation’s policy.
    
    sourceFile
    
    The result of executing § 5.4 Strip URL for use in reports on violation’s source file, if violation’s source file is not null, or null otherwise.
    
    sample
    
    violation’s sample.
    
    disposition
    
    violation’s disposition.
    
    statusCode
    
    violation’s status.
    
    lineNumber
    
    violation’s line number, if violation’s source file is not null, or null otherwise.
    
    columnNumber
    
    violation’s column number, if violation’s source file is not null, or null otherwise.
  2. Let settings object be violation’s global object’s relevant settings object.
  3. Generate and queue a report with the following arguments:
    
    context
    
    settings object
    
    type
    
    "csp-violation"
    
    destination
    
    directive’s value.
    
    data
    
    body

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.3 Document Directives), directives which govern aspects of navigation (in § 6.4 Navigation Directives), and directives which govern reporting (in § 6.5 Reporting Directives). These form the core of Content Security Policy; other directives are defined in a modular fashion in ancillary documents (see § 6.6 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 governs the creation of child navigables (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 "frame", "iframe", "object", or "embed".
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, a policy policy, and an origin self-origin:

Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
If the result of executing § 6.8.4 Should fetch directive execute on name, child-src and policy is "No", return "Allowed".
Return the result of executing the pre-request check for the directive whose name is name on request, policy, and self-origin 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, a policy policy and an origin self-origin:

Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
If the result of executing § 6.8.4 Should fetch directive execute on name, child-src and policy is "No", return "Allowed".
Return the result of executing the post-request check for the directive whose name is name on request, response, policy, and self-origin, 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.

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 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("wss://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, a policy policy, and an origin self-origin:

Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
If the result of executing § 6.8.4 Should fetch directive execute on name, connect-src and policy is "No", return "Allowed".
Let source list be directive’s value.
If request’s mode is "webtransport" and request’s WebTransport-hash list is not empty:
1. If source list contains a source expression which is an ASCII case-insensitive match for the keyword-source "'unsafe-webtransport-hashes'", return "Allowed".
2. Return "Blocked".
If the result of executing § 6.7.2.5 Does request match source list? on request, source list, and self-origin, is "Matches", return "Allowed".
Return "Blocked".

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, a policy policy and an origin self-origin:

Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
If the result of executing § 6.8.4 Should fetch directive execute on name, connect-src and policy is "No", return "Allowed".
Let source list be directive’s value.
If request’s mode is "webtransport" and request’s WebTransport-hash list is not empty:
1. If source list contains a source expression which is an ASCII case-insensitive match for the keyword-source "'unsafe-webtransport-hashes'", return "Allowed".
2. Return "Blocked".
If the result of executing § 6.7.2.6 Does response to request match source list? on response, request, source list, and self-origin, is "Matches", return "Allowed".
Return "Blocked".

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.2 Should request be blocked by Content Security Policy? and § 4.1.3 Should response to request be blocked by Content Security Policy? algorithms.

Resource hints such as prefetch and preconnect generate requests that aren’t tied to any specific fetch directive, but are instead governed by the union of servers allowed in all of a policy’s directives' source lists. If default-src is not specified, these requests will always be allowed. For more information, see § 8.6 Exfiltration. [HTML]

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-elem 'self';
                         script-src-attr 'self';
                         style-src-elem 'self';
                         style-src-attr '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-elem 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-elem https://example.com;
                         script-src-attr 'self';
                         style-src-elem 'self';
                         style-src-attr '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, a policy policy, and an origin self-origin:

Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
If the result of executing § 6.8.4 Should fetch directive execute on name, default-src and policy is "No", return "Allowed".
Return the result of executing the pre-request check for the directive whose name is name on request, policy, and self-origin, 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, a policy policy and an origin self-origin:

Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
If the result of executing § 6.8.4 Should fetch directive execute on name, default-src and policy is "No", return "Allowed".
Return the result of executing the post-request check for the directive whose name is name on request, response, policy, and self-origin, using this directive’s value for the comparison.

6.1.3.3. `default-src` Inline Check

This directive’s inline check algorithm is as follows:

Given an Element element, a string type, a policy policy and a string source:

Let name be the result of executing § 6.8.2 Get the effective directive for inline checks on type.
If the result of executing § 6.8.4 Should fetch directive execute on name, default-src and policy is "No", return "Allowed".
Otherwise, return the result of executing the inline check for the directive whose name is name on element, type, policy and source, 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 error, as the URL provided does 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, a policy policy, and an origin self-origin:

Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
If the result of executing § 6.8.4 Should fetch directive execute on name, font-src and policy is "No", return "Allowed".
If the result of executing § 6.7.2.5 Does request match source list? on request, this directive’s value, and self-origin, 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, a policy policy and an origin self-origin:

Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
If the result of executing § 6.8.4 Should fetch directive execute on name, font-src and policy is "No", return "Allowed".
If the result of executing § 6.7.2.6 Does response to request match source list? on response, request, this directive’s value, and self-origin, 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 child navigables. 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, a policy policy, and an origin self-origin:

Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
If the result of executing § 6.8.4 Should fetch directive execute on name, frame-src and policy is "No", return "Allowed".
If the result of executing § 6.7.2.5 Does request match source list? on request, this directive’s value, and self-origin, 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, a policy policy and an origin self-origin:

Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
If the result of executing § 6.8.4 Should fetch directive execute on name, frame-src and policy is "No", return "Allowed".
If the result of executing § 6.7.2.6 Does response to request match source list? on response, request, this directive’s value, and self-origin, 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, a policy policy, and an origin self-origin:

Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
If the result of executing § 6.8.4 Should fetch directive execute on name, img-src and policy is "No", return "Allowed".
If the result of executing § 6.7.2.5 Does request match source list? on request, this directive’s value, and self-origin, 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, a policy policy and an origin self-origin:

Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
If the result of executing § 6.8.4 Should fetch directive execute on name, img-src and policy is "No", return "Allowed".
If the result of executing § 6.7.2.6 Does response to request match source list? on response, request, this directive’s value, and self-origin, 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, a policy policy, and an origin self-origin:

Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
If the result of executing § 6.8.4 Should fetch directive execute on name, manifest-src and policy is "No", return "Allowed".
If the result of executing § 6.7.2.5 Does request match source list? on request, this directive’s value, and self-origin, 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, a policy policy and an origin self-origin:

Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
If the result of executing § 6.8.4 Should fetch directive execute on name, manifest-src and policy is "No", return "Allowed".
If the result of executing § 6.7.2.6 Does response to request match source list? on response, request, this directive’s value, and self-origin, 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, a policy policy, and an origin self-origin:

Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
If the result of executing § 6.8.4 Should fetch directive execute on name, media-src and policy is "No", return "Allowed".
If the result of executing § 6.7.2.5 Does request match source list? on request, this directive’s value, and self-origin, 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, a policy policy and an origin self-origin:

Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
If the result of executing § 6.8.4 Should fetch directive execute on name, media-src and policy is "No", return "Allowed".
If the result of executing § 6.7.2.6 Does response to request match source list? on response, request, this directive’s value, and self-origin, 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>

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 or embed element. This includes requests which would populate the child navigable 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 inside a navigable, and not as an embedded subresource via embed or object), any policy delivered along with that resource will be applied to the resulting 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, a policy policy, and an origin self-origin:

Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
If the result of executing § 6.8.4 Should fetch directive execute on name, object-src and policy is "No", return "Allowed".
If the result of executing § 6.7.2.5 Does request match source list? on request, this directive’s value, and self-origin, 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, a policy policy and an origin self-origin:

Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
If the result of executing § 6.8.4 Should fetch directive execute on name, object-src and policy is "No", return "Allowed".
If the result of executing § 6.7.2.6 Does response to request match source list? on response, request, this directive’s value, and self-origin, 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 acts as a default fallback for all script-like destinations (including worker-specific destinations if worker-src is not present). Unless granularity is desired script-src should be used in favor of script-src-attr and script-src-elem as in most situations there is no particular reason to have separate lists of permissions for inline event handlers and script elements.

The script-src directive governs six things:

Script requests MUST pass through § 4.1.2 Should request be blocked by Content Security Policy?.
Script responses MUST pass through § 4.1.3 Should response to request be blocked by Content Security Policy?.
Inline script blocks MUST pass through § 4.2.3 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" and "trusted-types-eval" source expressions:
- 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". Note: Since "unsafe-eval" acts as a global page flag, script-src-attr and script-src-elem are not used when performing this check, instead script-src (or it’s fallback directive) is always used.
The following WebAssembly execution sinks are gated on the "wasm-unsafe-eval" or the "unsafe-eval" source expressions:
Note: the "wasm-unsafe-eval" source expression is the more specific source expression. In particular, "unsafe-eval" permits both compilation (and instantiation) of WebAssembly and, for example, the use of the "eval" operation in JavaScript. The "wasm-unsafe-eval" source expression only permits WebAssembly and does not affect JavaScript.
Navigation to javascript: URLs MUST pass through § 4.2.3 Should element’s inline type behavior be blocked by Content Security Policy?. Such navigations will only execute script if every policy allows inline script, as per #3 above.

6.1.10.1. `script-src` Pre-request check

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

Given a request request, a policy policy, and an origin self-origin:

Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
If the result of executing § 6.8.4 Should fetch directive execute on name, script-src and policy is "No", return "Allowed".
Return the result of executing § 6.7.1.1 Script directives pre-request check on request, this directive, policy, and self-origin.

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, a policy policy and an origin self-origin:

Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
If the result of executing § 6.8.4 Should fetch directive execute on name, script-src and policy is "No", return "Allowed".
Return the result of executing § 6.7.1.2 Script directives post-request check on request, response, this directive, policy, and self-origin.

6.1.10.3. `script-src` Inline Check

This directive’s inline check algorithm is as follows:

Given an Element element, a string type, a policy policy and a string source:

Assert: element is not null or type is "navigation".
Let name be the result of executing § 6.8.2 Get the effective directive for inline checks on type.
If the result of executing § 6.8.4 Should fetch directive execute on name, script-src and policy is "No", return "Allowed".
If the result of executing § 6.7.3.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".

6.1.11. `script-src-elem`

The syntax for the directive’s name and value is described by the following ABNF:

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

The script-src-elem directive applies to all script requests and script blocks. Attributes that execute script (inline event handlers) are controlled via script-src-attr.

As such, the following differences exist when comparing to script-src:

script-src-elem applies to inline checks whose |type| is "script" and "navigation" (and is ignored for inline checks whose |type| is "script attribute").
script-src-elem’s value is not used for JavaScript execution sink checks that are gated on the "unsafe-eval" check.
script-src-elem is not used as a fallback for the worker-src directive. The worker-src checks still fall back on the script-src directive.

6.1.11.1. `script-src-elem` Pre-request check

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

Given a request request, a policy policy, and an origin self-origin:

Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
If the result of executing § 6.8.4 Should fetch directive execute on name, script-src-elem and policy is "No", return "Allowed".
Return the result of executing § 6.7.1.1 Script directives pre-request check on request, this directive, policy, and self-origin.

6.1.11.2. `script-src-elem` Post-request check

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

Given a request request, a response response, a policy policy and an origin self-origin:

Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
If the result of executing § 6.8.4 Should fetch directive execute on name, script-src-elem and policy is "No", return "Allowed".
Return the result of executing § 6.7.1.2 Script directives post-request check on request, response, this directive, policy, and self-origin.

6.1.11.3. `script-src-elem` Inline Check

This directive’s inline check algorithm is as follows:

Given an Element element, a string type, a policy policy and a string source:

Assert: element is not null or type is "navigation".
Let name be the result of executing § 6.8.2 Get the effective directive for inline checks on type.
If the result of executing § 6.8.4 Should fetch directive execute on name, script-src-elem, and policy is "No", return "Allowed".
If the result of executing § 6.7.3.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".

6.1.12. `script-src-attr`

The syntax for the directive’s name and value is described by the following ABNF:

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

The script-src-attr directive applies to event handlers and, if present, it will override the script-src directive for relevant checks.

6.1.12.1. `script-src-attr` Inline Check

This directive’s inline check algorithm is as follows:

Given an Element element, a string type, a policy policy and a string source:

Assert: element is not null or type is "navigation".
Let name be the result of executing § 6.8.2 Get the effective directive for inline checks on type.
If the result of executing § 6.8.4 Should fetch directive execute on name, script-src-attr and policy is "No", return "Allowed".
If the result of executing § 6.7.3.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".

6.1.13. `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.2 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.3 Should response to request be blocked by Content Security Policy?.
Inline style blocks MUST pass through § 4.2.3 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. [w3c/webappsec-csp Issue #212]

6.1.13.1. `style-src` Pre-request Check

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

Given a request request, a policy policy, and an origin self-origin:

Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
If the result of executing § 6.8.4 Should fetch directive execute on name, style-src and policy is "No", return "Allowed".
If the result of executing § 6.7.2.3 Does nonce match source list? on request’s cryptographic nonce metadata and this directive’s value is "Matches", return "Allowed".
If the result of executing § 6.7.2.5 Does request match source list? on request, this directive’s value, and self-origin, is "Does Not Match", return "Blocked".
Return "Allowed".

6.1.13.2. `style-src` Post-request Check

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

Given a request request, a response response, a policy policy, and an origin self-origin:

Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
If the result of executing § 6.8.4 Should fetch directive execute on name, style-src and policy is "No", return "Allowed".
If the result of executing § 6.7.2.3 Does nonce match source list? on request’s cryptographic nonce metadata and this directive’s value is "Matches", return "Allowed".
If the result of executing § 6.7.2.6 Does response to request match source list? on response, request, this directive’s value, and self-origin, is "Does Not Match", return "Blocked".
Return "Allowed".

6.1.13.3. `style-src` Inline Check

This directive’s inline check algorithm is as follows:

Given an Element element, a string type, a policy policy and a string source:

Let name be the result of executing § 6.8.2 Get the effective directive for inline checks on type.
If the result of executing § 6.8.4 Should fetch directive execute on name, style-src and policy is "No", return "Allowed".
If the result of executing § 6.7.3.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.14. `style-src-elem`

The syntax for the directive’s name and value is described by the following ABNF:

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

The style-src-elem directive governs the behaviour of styles except for styles defined in inline attributes.

6.1.14.1. `style-src-elem` Pre-request Check

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

Given a request request, a policy policy, and an origin self-origin:

Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
If the result of executing § 6.8.4 Should fetch directive execute on name, style-src-elem and policy is "No", return "Allowed".
If the result of executing § 6.7.2.3 Does nonce match source list? on request’s cryptographic nonce metadata and this directive’s value is "Matches", return "Allowed".
If the result of executing § 6.7.2.5 Does request match source list? on request, this directive’s value, and self-origin, is "Does Not Match", return "Blocked".
Return "Allowed".

6.1.14.2. `style-src-elem` Post-request Check

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

Given a request request, a response response, a policy policy, and an origin self-origin:

Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
If the result of executing § 6.8.4 Should fetch directive execute on name, style-src-elem and policy is "No", return "Allowed".
If the result of executing § 6.7.2.3 Does nonce match source list? on request’s cryptographic nonce metadata and this directive’s value is "Matches", return "Allowed".
If the result of executing § 6.7.2.6 Does response to request match source list? on response, request, this directive’s value, and self-origin, is "Does Not Match", return "Blocked".
Return "Allowed".

6.1.14.3. `style-src-elem` Inline Check

This directive’s inline check algorithm is as follows:

Given an Element element, a string type, a policy policy and a string source:

Let name be the result of executing § 6.8.2 Get the effective directive for inline checks on type.
If the result of executing § 6.8.4 Should fetch directive execute on name, style-src-elem and policy is "No", return "Allowed".
If the result of executing § 6.7.3.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".

6.1.15. `style-src-attr`

The syntax for the directive’s name and value is described by the following ABNF:

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

The style-src-attr directive governs the behaviour of style attributes.

6.1.15.1. `style-src-attr` Inline Check

This directive’s inline check algorithm is as follows:

Given an Element element, a string type, a policy policy and a string source:

Let name be the result of executing § 6.8.2 Get the effective directive for inline checks on type.
If the result of executing § 6.8.4 Should fetch directive execute on name, style-src-attr and policy is "No", return "Allowed".
If the result of executing § 6.7.3.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".

6.2. Other Directives

6.2.1. `webrtc`

The webrtc directive restricts whether connections may be established via WebRTC. The syntax for the directive’s name and value is described by the following ABNF:

directive-name  = "webrtc"
directive-value = "'allow'" / "'block'"

Given a page with the following Content Security Policy:

Content-Security-Policy: webrtc 'block'

No local ICE candidates will be surfaced, as no STUN checks will be made against the ICE server provided to the peer connection negotiated below; No connectivity-checks will be attempted to any remote candidates provided by JS; The connectionState will never transition to "connected" and instead transition directly from its initial state of "new" to "failed" shortly. Attempts to pc.restartIce() will repeat this outcome.

 <script>
   const iceServers = [{urls: "stun:stun.l.google.com:19302"}];
   const pc = new RTCPeerConnection({iceServers});
   pc.createDataChannel("");
   const io = new WebSocket('ws://example.com:8080');
   pc.onicecandidate = ({candidate}) => io.send({candidate});
   pc.onnegotiationneeded = async () => {
     await pc.setLocalDescription();
     io.send({description: pc.localDescription});
   };
   io.onmessage = async ({data: {description, candidate}}) => {
     if (description) {
       await pc.setRemoteDescription(description);
       if (description.type == "offer") {
         await pc.setLocalDescription();
         io.send({description: pc.localDescription});
       }
     } else if (candidate) await pc.addIceCandidate(candidate);
   };
</script>

6.2.1.1. `webrtc` Pre-connect Check

This directive’s webrtc pre-connect check is as follows:

If this directive’s value contains a single item which is an ASCII case-insensitive match for the string "'allow'", return "Allowed".
Return "Blocked".

6.2.2. `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

Content Security Policy Level 3

Abstract

Status of this document

1. Introduction

1.1. Examples

1.1.1. Control Execution

1.2. Goals

1.3. Changes from Level 2

2. Framework

2.1. Infrastructure

2.2. Policies

2.2.1. Parse a serialized CSP

2.2.2. Parse response’s Content Security Policies

2.3. Directives

2.3.1. Source Lists

2.4. Violations

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

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

3. Policy Delivery

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

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

3.3. The <meta> element

4. Integrations

4.1. Integration with Fetch

4.1.1. Report Content Security Policy violations for request

4.1.2. Should request be blocked by Content Security Policy?

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

4.1.4. Potentially report hash

4.2. Integration with HTML

4.2.1. Run CSP initialization for a Document

4.2.2. Retrieve the CSP list of an object

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

4.2.4. Should navigation request of type be blocked by Content Security Policy?

4.2.5. Should navigation response to navigation request of type in target be blocked by Content Security Policy?

4.2.6. Run CSP initialization for a global object

4.3. Integration with WebRTC

4.3.1. Should RTC connections be blocked for global?

4.4. Integration with ECMAScript

4.4.1. EnsureCSPDoesNotBlockStringCompilation(realm, parameterStrings, bodyString, codeString, compilationType, parameterArgs, bodyArg)

4.5. Integration with WebAssembly

4.5.1. EnsureCSPDoesNotBlockWasmByteCompilationrealm

5. Reporting

5.1. Violation DOM Events

5.2. Obtain the blockedURI of a violation’s resource

5.3. Obtain the deprecated serialization of violation

5.4. Strip URL for use in reports

5.5. Report a violation

6. Content Security Policy Directives

6.1. Fetch Directives

6.1.1. child-src

6.1.1.1. child-src Pre-request check

6.1.1.2. child-src Post-request check

6.1.2. connect-src

6.1.2.1. connect-src Pre-request check

6.1.2.2. connect-src Post-request check

6.1.3. default-src

6.1.3.1. default-src Pre-request check

6.1.3.2. default-src Post-request check

6.1.3.3. default-src Inline Check

6.1.4. font-src

6.1.4.1. font-src Pre-request check

6.1.4.2. font-src Post-request check

6.1.5. frame-src

6.1.5.1. frame-src Pre-request check

6.1.5.2. frame-src Post-request check

6.1.6. img-src

6.1.6.1. img-src Pre-request check

6.1.6.2. img-src Post-request check

6.1.7. manifest-src

6.1.7.1. manifest-src Pre-request check

6.1.7.2. manifest-src Post-request check

6.1.8. media-src

6.1.8.1. media-src Pre-request check

6.1.8.2. media-src Post-request check

6.1.9. object-src

6.1.9.1. object-src Pre-request check

6.1.9.2. object-src Post-request check

6.1.10. script-src

6.1.10.1. script-src Pre-request check

6.1.10.2. script-src Post-request check

2.2.2. Parse `response`’s Content Security Policies

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

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

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

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

3.3. The `<meta>` element

4.1.1. Report Content Security Policy violations for `request`

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

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

4.2.1. Run `CSP` initialization for a `Document`

4.2.2. Retrieve the CSP list of an `object`

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

4.2.4. Should `navigation request` of `type` be blocked by Content Security Policy?

4.2.5. Should `navigation response` to `navigation request` of `type` in `target` be blocked by Content Security Policy?

4.2.6. Run `CSP` initialization for a global object

4.3.1. Should RTC connections be blocked for `global`?

4.4.1. EnsureCSPDoesNotBlockStringCompilation(`realm`, `parameterStrings`, `bodyString`, `codeString`, `compilationType`, `parameterArgs`, `bodyArg`)

4.5.1. EnsureCSPDoesNotBlockWasmByteCompilation`realm`

5.2. Obtain the `blockedURI` of a violation’s `resource`

5.3. Obtain the deprecated serialization of `violation`

5.5. Report a `violation`

6.1.1. `child-src`

6.1.1.1. `child-src` Pre-request check

6.1.1.2. `child-src` Post-request check

6.1.2. `connect-src`

6.1.2.1. `connect-src` Pre-request check

6.1.2.2. `connect-src` Post-request check

6.1.3. `default-src`

6.1.3.1. `default-src` Pre-request check

6.1.3.2. `default-src` Post-request check

6.1.3.3. `default-src` Inline Check

6.1.4. `font-src`

6.1.4.1. `font-src` Pre-request check

6.1.4.2. `font-src` Post-request check

6.1.5. `frame-src`

6.1.5.1. `frame-src` Pre-request check

6.1.5.2. `frame-src` Post-request check

6.1.6. `img-src`

6.1.6.1. `img-src` Pre-request check

6.1.6.2. `img-src` Post-request check

6.1.7. `manifest-src`

6.1.7.1. `manifest-src` Pre-request check

6.1.7.2. `manifest-src` Post-request check

6.1.8. `media-src`

6.1.8.1. `media-src` Pre-request check

6.1.8.2. `media-src` Post-request check

6.1.9. `object-src`

6.1.9.1. `object-src` Pre-request check

6.1.9.2. `object-src` Post-request check

6.1.10. `script-src`

6.1.10.1. `script-src` Pre-request check

6.1.10.2. `script-src` Post-request check

6.1.10.3. `script-src` Inline Check

6.1.11. `script-src-elem`

6.1.11.1. `script-src-elem` Pre-request check

6.1.11.2. `script-src-elem` Post-request check

6.1.11.3. `script-src-elem` Inline Check

6.1.12. `script-src-attr`

6.1.12.1. `script-src-attr` Inline Check

6.1.13. `style-src`

6.1.13.1. `style-src` Pre-request Check

6.1.13.2. `style-src` Post-request Check

6.1.13.3. `style-src` Inline Check

6.1.14. `style-src-elem`

6.1.14.1. `style-src-elem` Pre-request Check

6.1.14.2. `style-src-elem` Post-request Check

6.1.14.3. `style-src-elem` Inline Check

6.1.15. `style-src-attr`

6.1.15.1. `style-src-attr` Inline Check

6.2.1. `webrtc`

6.2.1.1. `webrtc` Pre-connect Check

6.2.2. `worker-src`