3.2.1.1 Parsing

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

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

3.2.2.1 Parsing

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

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

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

3.2.2.2 Matching

To check whether a URI matches a source expression, the user agent MUST use an algorithm equivalent to the following:

1. Normalize the URI according to RFC 3986, section 6.
2. If the source expression a consists of a single U+002A ASTERISK character (*), then return does match.
3. If the source expression matches the grammar for scheme-source:
   1. If the URI's scheme is a case-insensitive match for the source expression's scheme, return does match.
   2. Otherwise, return does not match.
4. If the source expression matches the grammar for host-source:
   1. If the URI does not contain a host, then return does not match.
   2. Let uri-scheme, uri-host, and uri-port be the scheme, host, and port of the URI, respectively. If the URI does not have a port, then let uri-port be the default port for uri-scheme. Let uri-path be the path of the URI after decoding percent-encoded characters. If the URI does not have a path, then let uri-path be the U+002F SOLIDUS character (/).
   3. If the source expression has a scheme that is not a case insensitive match for uri-scheme, then return does not match.
   4. If the source expression does not have a scheme, return does not match if
      1. the scheme of the protected resource's URI is a case insensitive match for HTTP, and uri-scheme is not a case insensitive match for either HTTP or HTTPS
      2. the scheme of the protected resource's URI is not a case insensitive match for HTTP, and uri-scheme is not a case insensitive match for the scheme of the protected resource's URI.
   5. If the first character of the source expression's host is an U+002A ASTERISK character (*) and the remaining characters, including the leading U+002E FULL STOP character (.), are not a case insensitive match for the rightmost characters of uri-host, then return does not match.
   6. If the first character of the source expression's host is not an U+002A ASTERISK character (*) and uri-host is not a case insensitive match for the source expression's host, then return does not match.
   7. If the source expression does not contain a port and uri-port is not the default port for uri-scheme, then return does not match.
   8. If the source expression does contain a port, then return does not match if
      1. port does not contain an U+002A ASTERISK character (*), and
      2. port does not represent the same number as uri-port.
   9. If the source expression contains a non-empty path, then:
      1. Let decoded-path be the result of decoding path's percent-encoded characters.
      2. If the final character of decoded-path is the U+002F SOLIDUS character (/), and decoded-path is not a prefix of uri-path, then return does not match.
      3. If the final character of decoded-path is not the the U+002F SOLIDUS character (/), and decoded-path is not an exact match for uri-path then return does not match.
   10. Otherwise, return does match.
5. If the source expression is a case insensitive match for 'self' (including the quotation marks), then:
   1. Return does match if the URI has the same scheme, host, and port as the protected resource's URI (using the default port for the appropriate scheme if either or both URIs are missing ports).
6. Otherwise, return does not match.

A URI matches a source list, if, and only if, the URI matches at least one source expression in the set of source expressions obtained by parsing the source list. Notice that no URIs match an empty set of source expressions, such as the set obtained by parsing the source list 'none'.

3.2.2.3 Valid Nonces

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

3.2.2.4 Valid Hashes

An element's contents are the script block's source for script elements, or the value of the element's textContent IDL attribute for non-script elements such as style.

The algorithm digest of an element's contents is the result of applying algorithm to the element's contents.

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

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

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

3.2.2.5 Media Type List

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

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

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

3.2.2.6 Reporting

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

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

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

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

   blocked-uri

   The URI of the resource that was prevented from loading, stripped for reporting, or the empty string if the resource has no URI (inline script and inline style, for example).

   document-uri

   The address of the protected resource, stripped for reporting.

   effective-directive

   The name of the policy directive that was violated. This will contain the directive whose enforcement triggered the violation, even if that directive does not explicitly appear in the policy, but is implicitly activated via the default-src directive.

   original-policy

   The original policy, as received by the user agent.

   referrer

   The referrer attribute of the protected resource, or the empty string if the protected resource has no referrer.

   status-code

   The status-code of the HTTP response that contained the protected resource, if the protected resource was obtained over HTTP. Otherwise, the number 0.

   violated-directive

   The policy directive that was violated, as it appears in the policy. This will contain the default-src directive in the case of violations caused by falling back to the default sources when enforcing a directive.

2. If a specific line or a specific file can be identified as the cause of the violation (for example, script execution that violates the script-src directive), the user agent MAY add the following keys and values to violation:

   source-file

   The URI of the resource where the violation occurred, stripped for reporting.

   line-number

   The line number in source-file on which the violation occurred.

   column-number

   The column number in source-file on which the violation occurred.

3. Return violation.

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

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

To report a violation, the user agent MUST:

1. Fire a violation event at the protected resource's Document, and
2. If the set of report URIs is non-empty, send violation reports to each.

3.2.4.1 SecurityPolicyViolationEvent Events

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

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

3.2.5.1 base-uri

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

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

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

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

4. If the previous step was not successful, or the result of the previous step does not match the allowed base URIs, then the document base URL is fallback base URL. Otherwise, it is the result of the previous step.

3.2.5.2 child-src

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

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

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

3.2.5.3 connect-src

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

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

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

Whenever the user agent fetches a URI (including when following redirects) in the course of one of the following activities, if the URI does not match the allowed connection targets, the user agent MUST act as if it had received an empty HTTP 400 response and report a violation:

• Processing the send() method of an XMLHttpRequest object.
• Processing the WebSocket constructor.
• Processing the EventSource constructor.

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

3.2.5.4 default-src

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

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

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

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

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

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

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

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

3.2.5.5 font-src

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

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

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

Whenever the user agent fetches a URI (including when following redirects) in the course of one of the following activities, if the URI does not match the allowed font sources, the user agent MUST act as if it had received an empty HTTP 400 response and report a violation:

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

3.2.5.6 form-action

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

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

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

Whenever the user agent fetches a URI (including when following redirects) in the course of one of the following activities, if the URI does not match the allowed form actions, the user agent MUST act as if it had received an empty HTTP 400 response and report a violation:

• Processing an HTML form element.

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

3.2.5.7 frame-ancestors

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

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

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

The term allowed frame ancestors refers to the result of parsing the frame-ancestors directive's value as a source list. Note that this directive is not influenced by the default sources. If a frame-ancestors directive is not explicitly included in the policy, the allowed frame ancestors is "*".

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

1. Let nestedContext be the nested browsing context into which the protected resource is being loaded.
2. Let ancestorList be the list of all ancestor browsing contexts of nestedContext.
3. For each ancestorContext in ancestorList:
   1. Let document be ancestorContext's active document.
   2. If document's URL does not match the allowed frame ancestors, the user agent MUST:
      1. Abort loading the protected resource.
      2. Act as if it received an empty HTTP 200 response.
      3. Parse the sandboxing directive using the empty string as the input and the newly created document's forced sandboxing flag set as the output.

Steps 2.2 and 2.3 ensure that the blocked frame appears to be a normal cross-origin document's load. If these steps are ignored, leakage of a document's policy state is possible. The user agent MAY implement these steps by instead redirecting the user to friendly error page in a unique origin which provides the option of opening the blocked page in a new top-level browsing context.

Note that the frame-ancestors directive will be ignored when monitoring a policy, and when a contained in a policy defined via a meta element.

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

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

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

3.2.5.8 frame-src

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

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

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

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

Whenever the user agent fetches a URI (including when following redirects) in the course of one of the following activities, if the URI does not match the allowed frame sources, the user agent MUST act as if it had received an empty HTTP 400 response and report a violation:

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

3.2.5.9 img-src

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

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

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

Whenever the user agent fetches a URI (including when following redirects) in the course of one of the following activities, if the URI does not match the allowed image sources, the user agent MUST act as if it had received an empty HTTP 400 response and report a violation:

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

3.2.5.10 media-src

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

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

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

Whenever the user agent fetches a URI (including when following redirects) in the course of one of the following activities, if the URI does not match the allowed media sources, the user agent MUST act as if it had received an empty HTTP 400 response:

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

3.2.5.11 object-src

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

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

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

Whenever the user agent fetches a URI (including when following redirects) in the course of one of the following activities, if the URI does not match the allowed object sources, the user agent MUST act as if it had received an empty HTTP 400 response and report a violation:

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

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

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

3.2.5.12 plugin-types

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

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

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

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

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

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

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

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

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

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

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

3.2.5.13 referrer

The referrer directive specifies a referrer policy that the user agent applies when determining what refererrer information should be included with requests made, and browsing contexts created from the context of the protected resource. The syntax for the name and value of the directive are described by the following ABNF grammar:

directive-name    = "referrer"
directive-value   = "never" / "default" / "origin" / "always"

Note that the directive name does not share the HTTP header's misspelling.

The term referrer policy refers to the value of the referrer directive, or to the empty string if no referrer directive is present in the protected resource's policy.

If the value of the referrer directive is invalid, the user agent SHOULD set the referrer policy to never.

Replace step 7 of the "Determine referrer" algorithm defined in Fetch with the following:

7. If referrer is null, or if the referrer policy is never, return null.
8. If the referrer policy is origin, return the ASCII serialization of referrer.
9. If the referrer policy is always, return referrer. Note that this might cause HTTPS referrer information to be sent over the network as part of unencrypted HTTP requests.
10. Return null if the scheme component of referrer represents a protocol that uses transport-layer security and the scheme component of the resource being fetched does not.
11. Return referrer.

Note: This specification should not be interpreted as limiting user agents' ability to apply other restrictions to limit referrer leakage.

Content-Security-Policy: referrer never;

3.2.5.14 reflected-xss

The reflected-xss directive instructs a user agent to active or disactivate any heuristics used to filter or block reflected cross-site scripting attacks. The syntax for the name and value of the directive are described by the following ABNF grammar:

directive-name    = "reflected-xss"
directive-value   = "allow" / "block" / "filter"

A user agent with support for XSS protection MUST enforce this directive as follows:

• If the value of the directive is allow, the user agent MUST disable its active protections against reflected cross-site scripting attacks for the protected resource.
• If the value of the directive is filter, the user agent MUST enable its active protections against reflected cross-site scripting attacks for the protected resource. This might result in filtering script that is believed to be reflected being filtered or selectively blocking script execution.
• If the value of the directive is block, the user agent MUST stop rendering the protected resource upon detection of reflected script, and instead act as though it received an empty HTTP 400 response for the protected resource itself.

If the user agent's active protections against reflected cross-site scripting attacks detect or prevent script execution, the user agent MUST report a violation.

3.2.5.15 report-uri

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

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

The set of report URIs is the value of the report-uri directive, each resolved relative to the protected resource's URI.

The process of sending violation reports to the URIs specified in this directive's value is defined in this document's Reporting section.

Note that the report-uri directive will be ignored if contained within a meta element.

3.2.5.16 sandbox

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

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

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

Note that the sandbox directive will be ignored when monitoring a policy, and when a contained in a policy defined via a meta element.

Content-Security-Policy: sandbox

Content-Security-Policy: sandbox allow-scripts

3.2.5.17 script-src

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

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

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

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

• Whenever the user agent would execute an inline script from a script element that lacks a valid nonce and lacks a valid hash for the allowed script sources, instead the user agent MUST NOT execute script, and MUST report a violation.
• Whenever the user agent would execute an inline script from an inline event handler, instead the user agent MUST NOT execute script, and MUST report a violation.
• Whenever the user agent would execute script contained in a javascript URI, instead the user agent MUST NOT execute the script, and MUST report a violation. (The user agent SHOULD ignore this step when processing script contained in "bookmarklets").

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

• Instead of evaluating their arguments, both operator eval and function eval [ECMA-262] MUST throw a SecurityError exception. [DOM4]
• When called as a constructor, the function Function [ECMA-262] MUST throw a SecurityError exception. [DOM4]
• When called with a first argument that is non-callable (e.g., not a function), the setTimeout function MUST return zero without creating a timer.
• When called with a first argument that is non-callable (e.g., not a function), the setInterval function MUST return zero without creating a timer.

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

Whenever the user agent fetches a URI (including when following redirects) in the course of one of the following activities, if the URI does not match the allowed script sources, the user agent MUST act as if it had received an empty HTTP 400 response and report a violation:

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

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

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

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

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

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

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

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

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

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

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

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

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

3.2.5.18 style-src

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

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

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

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

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

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

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

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

Whenever the user agent fetches a URI (including when following redirects) in the course of one of the following activities, if the URI does not match the allowed style sources, the user agent MUST act as if it had received an empty HTTP 400 response and report a violation:

• Requesting external style sheets, such as when processing the href attribute of a link element with a rel attribute containing the token stylesheet or when processing the @import directive in a stylesheet.

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

3.2.7.1 Cascading Style Sheet (CSS) Parsing

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

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

3.2.7.2 Violation Reports

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

3.2.9.1 Content-Security-Policy

Header field name: Content-Security-Policy

Applicable protocol: http

Status: standard

Author/Change controller: W3C

Specification document: this specification (See Content-Security-Policy Header Field)

3.2.9.2 Content-Security-Policy-Report-Only

Header field name: Content-Security-Policy-Report-Only

Applicable protocol: http

Status: standard

Author/Change controller: W3C

Specification document: this specification (See Content-Security-Policy-Report-Only Header Field)