Content Security Policy

3.1. Content-Security-Policy Header Field

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.3. HTML meta Element

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

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

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

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

1. If the Document’s head element is not an ancestor of the meta element, abort these steps.
2. If the meta element lacks a content attribute, abort these steps.
3. Let policy be the value of the content attribute of the meta element.
4. Let directive-set be the result of parsing policy.
5. Remove all occurrences of reflected-xss, report-uri, frame-ancestors, and sandbox directives from directive-set.

   Note: User agents are encouraged to issue a warning to developers if one or more of these directives are included in a policy delivered via meta.

6. Enforce each of the directives in directive-set, as defined for each directive type.

Authors are strongly encouraged to place meta elements as early in the document as possible, because policies in meta elements are not applied to content which preceds 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 §3.5 Enforcing multiple policies.

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

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

3.4. The CSP HTTP Request Header

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

"CSP:" 1#csp-header-value

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

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

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

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

3.5. Enforcing multiple policies

This section is not normative.

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

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

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

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

3.6. Policy applicability

This section is not normative.

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

4.1. Policy Syntax

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

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

4.2. Source List Syntax

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

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

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

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

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

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

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

partial interface HTMLScriptElement {
  attribute DOMString nonce;
};

partial interface HTMLStyleElement {
  attribute DOMString nonce;
};

4.3. Media Type List Syntax

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

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

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

4.4. 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 filesystem), 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 originally requested URL of the resource that was prevented from loading, stripped for reporting, or the empty string if the resource has no URL (inline script and inline style, for example).

   document-uri

   The address of the protected resource, stripped for reporting.

   effective-directive

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

   original-policy

   The original policy, as received by the user agent.

   referrer

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

   status-code

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

   violated-directive

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

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 URL of the resource where the violation occurred, stripped for reporting.

   line-number

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

   column-number

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

3. Return violation.

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

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

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

To report a violation, the user agent MUST:

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

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

5.1. Workers

Whenever a user agent runs a worker:

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

5.2. srcdoc iframes

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

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

6.1. Strawman DOM API

This is a sketch of what an API might look like. It is neither complete nor finalized; take it as an outline for discussion, nothing more. The general idea is to model CSP as a set of SecurityPolicy objects, each composed of a sequence of directives.

The following is what I think we’ll need for source-list directives (§4.2 Source List Syntax). It’ll need some adjustment to deal well with the other directive types.

[ NoInterfaceObject ]
interface SecurityPolicySource {
};

[Constructor(DOMString sourceExpression)]
interface SecurityPolicySourceURL : SecurityPolicySource {
    boolean matchesURL(DOMString url);

    readonly attribute DOMString scheme;
    readonly attribute DOMString host;
    readonly attribute DOMString port;
    readonly attribute DOMString path;

    readonly attribute boolean hostWildcard;
    readonly attribute boolean portWildcard;
};

enum SecurityPolicyHashAlgorithm { "SHA-256", "SHA-384", "SHA-512" };

[Constructor(DOMString sourceExpression)]
interface SecurityPolicySourceHash : SecurityPolicySource {
    boolean matchesNode(Node node);

    readonly attribute SecurityPolicyHashAlgorithm algorithm;
    readonly attribute DOMString hash;
};

[Constructor(DOMString sourceExpression)]
interface SecurityPolicySourceNonce : SecurityPolicySource {
    boolean matchesNode(Node node);

    readonly attribute DOMString nonce;
};

[ NoInterfaceObject ]
interface SecurityPolicyDirective {
};

[Constructor(DOMString directiveName, DOMString directiveValue)]
interface SecurityPolicySourceListDirective : SecurityPolicyDirective {
    boolean matchesURL(DOMString url);
    boolean matchesNode(Node node);

    readonly attribute boolean allowRedirects;
    readonly attribute boolean allowEval;

    // TODO: Bikeshed doesn’t like `Sequence`?
    readonly attribute SecurityPolicySource[] sources;
    readonly attribute DOMString directive;
};

enum SecurityPolicyMode {
    "EnforceMode",
    "ReportOnlyMode"
};

[Constructor(DOMString policy, SecurityPolicyMode mode)]
interface SecurityPolicy {
    // Fetch’s 'Request' object has a URL and a RequestContext, which
    // should be everything we need here to check outgoing network
    // requests. It lacks a redirect flag; not sure how to model that
    // yet. TODO.
    boolean allowRequest(Request request);

    // Inline checks can be done on a Node basis; given an HTMLScriptElement,
    // we’d skim through the `script-src` directive’s sources, checking for
    // hash and nonce matches.
    boolean allowNode(Node node);

    // One-offs. Maybe there’s a good way to fold these in somehow?
    boolean allowEval();
    boolean allowInlineEventHandler();

    // TODO: Bikeshed doesn’t like `Sequence`?
    readonly attribute SecurityPolicyDirective[] directives;

    readonly attribute SecurityPolicyMode mode;
    readonly attribute URL reportingEndpoint;
};

6.2. SecurityPolicyViolationEvent Interface

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

documentURL, of type DOMString, readonly

Refer to the document-uri property of violation reports for a description of this property.

referrer, of type DOMString, readonly

Refer to the referrer property of violation reports for a description of this property.

blockedURL, of type DOMString, readonly

Refer to the blocked-uri property of violation reports for a description of this property.

violatedDirective, of type DOMString, readonly

Refer to the violated-directive property of violation reports for a description of this property.

effectiveDirective, of type DOMString, readonly

Refer to the effective-directive property of violation reports for a description of this property.

originalPolicy, of type DOMString, readonly

Refer to the original-policy property of violation reports for a description of this property.

statusCode, of type DOMString, readonly

Refer to the status-code property of violation reports for a description of this property.

sourceFile, of type DOMString, readonly

Refer to the source-file property of violation reports for a description of this property.

lineNumber, of type long, readonly

Refer to the line-number property of violation reports for a description of this property.

columnNumber, of type long, readonly

Refer to the column-number property of violation reports for a description of this property.

6.3. SecurityPolicyViolationEventInit Interface

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

documentURL, of type DOMString

Refer to the document-uri property of violation reports for a description of this property.

referrer, of type DOMString

Refer to the referrer property of violation reports for a description of this property.

blockedURL, of type DOMString

Refer to the blocked-uri property of violation reports for a description of this property.

violatedDirective, of type DOMString

Refer to the violated-directive property of violation reports for a description of this property.

effectiveDirective, of type DOMString

Refer to the effective-directive property of violation reports for a description of this property.

originalPolicy, of type DOMString

Refer to the original-policy property of violation reports for a description of this property.

sourceFile, of type DOMString

Refer to the source-file property of violation reports for a description of this property.

lineNumber, of type long

Refer to the line-number property of violation reports for a description of this property.

columnNumber, of type long

Refer to the column-number property of violation reports for a description of this property.

6.4. Firing Violation Events

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

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

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

7.1. base-uri

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

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

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

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

Step 4 of the algorithm defined in HTML5 to obtain a document’s base URL (resolution of the href attribute of the base element) 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 URLs for the protected resource, then the document base URL is fallback base URL. Otherwise, it is the result of the previous step.

7.2. child-src

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

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

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

7.3. connect-src

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

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

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

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

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

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

7.4. default-src

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

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

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

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

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

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

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

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

7.5. font-src

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

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

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

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

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

7.6. form-action

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

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

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

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

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

7.7. frame-ancestors

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

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

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

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

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

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

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

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

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

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

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

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

7.8. frame-src

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

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

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

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

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

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

7.9. img-src

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

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

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

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

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

7.10. manifest-src

The manifest-src directive restricts which application manifest [MANIFEST] the user agent may apply to the protected resource. The syntax for the name and value of the directive are described by the following ABNF grammar:

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

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

Whenever the user agent fetches a URL that does not match the allowed manifest sources in the course of executing the steps for obtaining a manifest, the user agent MUST act as if there was a fatal network error and no resource was obtained, and report a violation.

7.11. media-src

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

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

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

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

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

7.12. object-src

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

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

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

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

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

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

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

7.13. plugin-types

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

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

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

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

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

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

Whenever the user agent creates a plugin document as the active document of a child browsing context of 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 as the active document of a child browsing context of 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>

7.14. reflected-xss

The reflected-xss directive instructs a user agent to activate or deactivate any heuristics used to filter or block reflected cross-site scripting attacks. 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 if there was a fatal network error and no resource was obtained, and report a violation:

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.

Note: The reflected-xss directive will be ignored if contained within a meta element.

7.15. report-uri

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

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

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

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

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

7.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   = "" / sandbox-token *( 1*WSP sandbox-token )
sandbox-token     = <token from RFC 7230>

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

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

7.16.1. Sandboxing and Workers

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

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

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

Content-Security-Policy: sandbox

Content-Security-Policy: sandbox allow-scripts

7.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 URL, instead the user agent MUST NOT execute the script, and MUST report a violation.

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

• Instead of evaluating their arguments, both operator eval and function eval [ECMA-262] MUST throw an EvalError exception.
• When called as a constructor, the function Function [ECMA-262] MUST throw an EvalError exception.
• When called with a first argument which returns false when passed into IsCallable() (a string, for example), the setTimeout() function MUST return zero without creating a timer.
• When called with a first argument which returns false when passed into IsCallable() (a string, for example), the setInterval() function MUST return zero without creating a timer.

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

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

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'

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

Content-Security-Policy: script-src 'sha256-qznLcsROx4GACP2dm0UCKCzCG+HiZ1guq6ZZDob/Tng='

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

7.18. style-src

The style-src directive restricts which styles 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    = "style-src"
directive-value   = source-list

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

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

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

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

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

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

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

• Requesting an external stylesheet when processing the href of a link element whose rel attribute contains the token stylesheet.
• Requesting an external stylesheet when processing the <<@import>> directive.
• Requesting an external stylesheet when processing a Link HTTP response header field. [RFC5988]

  Note: As this stylesheet might be prefetched before a Document actually exists, user agents will need to carefully consider how to instantiate a meaningful policy against which to compare this request. See §10.1 Processing Complications for more detail.

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

9.1. Cascading Style Sheet (CSS) Parsing

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

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

9.2. Violation Reports

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

11.1. Content-Security-Policy

Header field name

Content-Security-Policy

Applicable protocol

http

Status

standard

Author/Change controller

W3C

Specification document

This specification (See Content-Security-Policy Header Field)

11.2. Content-Security-Policy-Report-Only

Header field name

Content-Security-Policy-Report-Only

Applicable protocol

http

Status

standard

Author/Change controller

W3C

Specification document

This specification (See Content-Security-Policy-Report-Only Header Field)

11.3. CSP

Header field name

CSP

Applicable protocol

http

Status

standard

Author/Change controller

W3C

Specification document

This specification (See §3.4 The CSP HTTP Request Header)