Content Security Policy: Embedded Enforcement

1. Introduction

This section is not normative.

Content Security Policy is a great defense against cross-site scripting attacks, allowing developers to harden their own sites against injection of malicious script, style, and other resource types. It does not, however, give developers the ability to apply restrictions to third-party content loaded in via iframe. Allowing CSP to apply directly to these third-party contexts would be dangerous; CSP gives quite granular control over resource loading, and it’s very possible to introduce vulnerabilities into an otherwise secure page by denying it access to particular scripts. We’ve seen these kinds of issues in past features such as X-XSS-Protection, so we must be careful to avoid reintroducing them in a new form.

That said, it would be quite useful to be able to place restrictions upon widgets, advertisements, and other kinds of third-party content. This document proposes a mechanism which relies on an explicit opt-in from the embedded content, which ought to make it possible for widgets to cooperate with their embedders to negotiate a reasonable set of restrictions.

In short, the embedder proposes a Content Security Policy by setting an attribute on an iframe element. This policy is transmitted along with the HTTP request for the framed content in an HTTP request header (`Sec-Required-CSP`). If the embedded content can accept that policy, it can enforce it by returning a `Content-Security-Policy` or `Allow-CSP-From` header along with the response.

If the response contains a policy at least as strict as the policy which the embedder requested, or accepts the embedder-provided policy, then the user agent will render the embedded content. If no such assertion is present, the response will be blocked.

1.1. Examples

<iframe src="https://advertisements-r-us.example.com/ad1.cfm"
        csp="script-src https://trusted-cdn.example.com/">
</iframe>

GET / HTTP/1.1
Host: advertisements-r-us.example.com
...
Sec-Required-CSP: script-src https://trusted-cdn.example.com/
...

HTTP/1.1 200 OK
...
Allow-CSP-From: https://example.com

HTTP/1.1 200 OK
...
Content-Security-Policy: script-src https://trusted-cdn.example.com/; object-src 'none'

HTTP/1.1 200 OK
...
Content-Security-Policy: script-src https://trusted-cdn.example.com/, object-src 'none'

2. Framework

At a high level, this document describes a mechanism by which an embedee can opt-into a set of restrictions specified by its embedder. The mechanism involves a few steps:

1. The embedder specifies a required policy via a csp attribute on an iframe element. This is described in more detail in § 2.1 <iframe>’s csp attribute.

2. That attribute’s value will be sent along as a `Sec-Required-CSP` request header with any navigation request that targets the iframe’s child navigable. This header is described in more detail in § 2.2 The Sec-Required-CSP HTTP Request Header.

3. The server can examine the `Sec-Required-CSP` header to determine whether it wishes to accept the required policy.If so, it can implicitly opt-in by sending a `Content-Security-Policy` header in the response that contains a policy which is at least as strong as the required policy, or explicitly opt-in by sending an `Allow-CSP-From` header in the response that enables the embedding origin to set whatever policy it wishes. The explicit mechanism is straightforward, described in § 2.3 The Allow-CSP-From HTTP Response Header. The implicit mechanism is quite complicated, and comprises the entire § 3 Implicit Policy Acceptance section.

   If the server doesn’t wish to accept the required policy, it can return an explicit error, or simply return the usual data without either a matching `Content-Security-Policy` header or an `Allow-CSP-From` header. In this case, the user agent will block the response. This integration with HTML’s navigate algorithm is described in § 2.4 Integration with HTML, and the blocking mechanism is spelled out in § 4.1 Is response to request blocked by requiredCSP?.

2.1. <iframe>’s csp attribute

iframe elements have a csp attribute, which specifies the policy that an embedded document must agree to enforce upon itself. For example, the following HTML would load https://embedee.example.com/, and ensure that object-src 'none' was enforced upon it:

<iframe src="https://embedee.example.com/" csp="object-src 'none'">
</iframe>

A string (value) is a valid attribute value for a given element (element)'s csp attribute if all of the following statements are true:

1. value is not the empty string.

2. value’s length is less than or equal to 4096.

   Note: We enforce a maximum length on the csp attribute’s value to protect servers from potentially confusing input. See § 5.4 Header Length below.

3. value matches the serialized-policy ABNF grammar defined in [CSP].

4. One of the following statements is true:

   1. element’s node document’s policy container’s required CSP is null.

   2. The result of parsing value as "enforce" is subsumed by element’s node document’s policy container’s required CSP.

5. The result of parsing value as "enforce" has a directive set that does not contain any of the following directives:

   • report-uri

   • report-to

iframe’s csp attribute has a corresponding IDL attribute, defined by the following WebIDL grammar [WEBIDL]:

partial interface HTMLIFrameElement {
  [CEReactions] attribute DOMString csp;
};

The csp IDL attribute must reflect the element’s csp attribute.

Upstream this to all the HTMLs.

2.2. The Sec-Required-CSP HTTP Request Header

In order to ensure that the embedded resource can decide whether or not it is willing to adhere to the embedder’s requirements, the policy expressed in an iframe’s csp attribute is communicated along with affected navigation requests via a "Sec-Required-CSP" HTTP request header. The header’s value is represented by the following ABNF [RFC5234]:

Sec-Required-CSP = serialized-policy

A user agent MUST NOT send more than one HTTP response header field named "Sec-Required-CSP", and any such header MUST NOT contain more than one serialized-policy.

Servers MUST process only the first policy in the first such header received. As discussed in § 5.3 Header Reflection, servers SHOULD also carefully consider the implications of simply reflecting a policy back to a client. If the server wishes to simply accept an embedder’s requirements, the `Allow-CSP-From` header is a safer choice.

This header is set as part of HTML’s navigate algorithm (see § 2.4 Integration with HTML for details on the hook that calls the following algorithm):

2.3. The Allow-CSP-From HTTP Response Header

An embedee can opt-into accepting a policy specified by an embedder by responding with a "Allow-CSP-From" HTTP response header. The header’s value is represented by the following ABNF [RFC5234]:

Allow-CSP-From = origin-or-null / wildcard

2.4. Integration with HTML

1. iframe elements have a csp attribute, defined in § 2.1 <iframe>’s csp attribute.

2. Add a required CSP item to the policy container struct, which is a serialized CSP or null, and is initially null.

3. Add a required CSP item to the target snapshot params struct, which is a serialized CSP or null.

4. Update HTML’s snapshotting target snapshot params algorithm to set the new required CSP item to the result of determine the required CSP given targetNavigable.

5. Add a required CSP item to the navigation params struct, which is a serialized CSP or null.

6. Update the navigate algorithm to set the required CSP of the navigation params struct created in step 18.7.7 to targetSnapshotParams’s required CSP.

7. Add the following step to HTML’s create navigation params by fetching algorithm, after request is created:

   1. set the Sec-Required-CSP header for request and targetSnapshotParams’s required CSP.

8. Update create navigation params by fetching to set the required CSP of the returned navigation params to targetSnapshotParams’s required CSP.

9. Update create navigation params from a srcdoc resource to set the required CSP of the returned navigation params to targetSnapshotParams’s required CSP.

10. Add an optional requiredCSP (a serialized CSP or null, defaulting to null) as an argument to HTML’s creating a policy container from a fetch response algorithm, and add the following steps:

    1. If requiredCSP is not null:

       1. Let required policy be the result of parsing requiredCSP as "enforce".

       2. Append required policy to result’s CSP list.

       3. Set result’s required CSP to requiredCSP.

11. Update create navigation params by fetching to pass targetSnapshotParams’s required CSP to creating a policy container from a fetch response.

12. Add the following to the list of conditions in HTML’s navigate algorithm that cause the navigation to be blocked (e.g. after the X-Frame-Options check):

    • The § 4.1 Is response to request blocked by requiredCSP? algorithm returns "Blocked" when executed upon navigationParams’s response, navigationParams’s request, and navigationParams’s required CSP.

2.4.1. Required CSP

Upstream this.

3. Implicit Policy Acceptance

An embedee can explicitly accept a policy requirement specified by its embedder by returning an `Allow-CSP-From` header along with a response. The requirement can also be implicitly accepted by delivering a `Content-Security-Policy` header that contains a policy (or set of policies) whose net effect is at least as strict as the policy required by the embedder.

"At least as strict", however, isn’t very precise. Simple cases are straightforward: if an embedder requires object-src https://cdn.example.com, the embedee can respond with object-src 'none'. Since every possible resource that would be blocked by the former would also be blocked by the latter (because it allows no objects at all), we wouldn’t block the embedding. CSP’s syntactical complexity makes this a little bit difficult to reason about for more complicated cases. For instance, given script-src 'unsafe-inline' http: 'sha256-abc...def', it might appear that script-src 'unsafe-inline' would be a subset of the required policy. The presence of the hash-source expression, however means that 'unsafe-inline' is ignored in the required policy, so the latter policy would actually allow more than the former, despite appearances.

To formalize the concept a bit, we need a few terms, and more than a few algorithms:

• A content security policy object (A) is said to subsume another content security policy object (B) if B is at least as strict as A. In this case B could also be said to be subsumed by A. The details of determining "at least as strict"ness are spelled out in § 3.2 Subsumption.

• When multiple policies are present, they have a combined effect which is described in "The effect of multiple policies". Here, we’ll talk about the combined effect of a CSP list as their intersection. The details of determining that are spelled out in § 3.1 Intersection.

• A content security policy object (A) is said to subsume a CSP list if A subsumes their intersection.

3.1. Intersection

3.1.1. CSP List intersection

The intersection of a CSP list (list) for an origin (origin) is a single Content Security Policy object representing their net effect, produced by the following algorithm:

Note: It isn’t always possible to represent the intersection of multiple policies as a single policy. Consider script-src 'unsafe-inline' and script-src 'nonce-abc', for instance: the former allows only inline script, the latter allows only inline or externalized script with a particular token. The net effect (only inline script with a particular token) cannot be created with a single policy. Dealing with such policies is, for the moment, left as an exercise for the reader.

We shouldn’t make the reader do this exercise. We should also provide guidance on how to handle intersections that aren’t representable as a single policy (e.g. by maintaining a list of policies).

1. Let result be a content security policy object with an empty directive set disposition of "enforce".

2. For each policy in list:

   1. If policy’s disposition is "report", continue.

   2. Set result to the intersection of result and policy for origin.

3. Return result.

«
    "default-src 'self' http://example.com http://example.net;
     connect-src 'none';",
    "connect-src http://example.com/;
     script-src http://example.com/",
    "style-src 'self';
     script-src http://example.com/ http://example.net",
»

"default-src 'self' http://example.com http://example.net;
 connect-src 'none';
 script-src http://example.com/;
 style-src 'self'"

3.1.2. Policy Intersection

The intersection of two Content Security Policy objects (A and B) for an origin (origin) is a single Content Security Policy object representing their combined effect, produced by the following algorithm:

1. Assert: A and B both have a disposition of "enforce".

2. If A’s directive set is empty, return B.

3. If B’s directive set is empty, return A.

4. Let policy be a new content security policy object with an empty directive set, and a disposition "enforce".

5. Let directive names be an empty set.

6. For each directive in A:

   1. Append directive’s name to directive names.

7. For each directive in B:

   1. Append directive’s name to directive names.

8. For each directive name in directive names:

   1. If directive name is "report-uri", "report-to", continue.

   2. Let directive A be the effective directive value for directive name and A.

   3. Let directive B be the effective directive value for directive name and B.

   4. Assert: directive A and directive B are not both null, and either both of their values are source lists, or neither of their values are source lists.

   5. If either directive A or directive B has a value which is not a source list, continue.

      We need to extend this definition to handle things that are not source lists. Also, we should be more precise about this, perhaps by defining a term like "source list directive" that we could check against directive name.

   6. If directive A is null:

      1. Let directive be a new directive with the following properties:

         name

         directive name

         value

         directive B’s value

      2. append a directive to policy’s directive set.

      3. Continue.

   7. If directive B is null:

      1. Let directive be a new directive with the following properties:

         name

         directive name

         value

         directive A’s value

      2. append a directive to policy’s directive set.

      3. Continue.

   8. Let directive value be the intersection of directive A’s value, directive B’s value, directive name, and origin.

   9. Let directive be a new directive with he following properties:

      name

      directive name

      value

      directive value

   10. Append directive to policy’s directive set.

9. Return policy.

"default-src 'self' http://example.com http://example.net;
 connect-src 'none';"

and

"connect-src http://example.com/;
 script-src http://example.com/"

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

3.1.3. Source List Intersection

The intersection of two source lists for a directive name (name) and an origin (origin) is a source list representing their net effect. If no such source list exists (for example, https://example.com/ in A and https://not-example.com in B), then the intersection will be the list « 'none' ».

1. Let effective A be the effective source list for A, name, and origin.

2. Let effective B be the effective source list for B, name, and origin.

3. If either effective A or effective B is « 'none' », return « 'none' ».

4. If effective A is empty, return effective B.

5. If effective B is empty, return effective A.

6. Let schemes be an empty set.

7. Let intersection be an empty source list.

8. For each expression B in effective B:

   1. If expression B matches the scheme-source grammar and expression B is contained in effective A, then append expression B to schemes.

      Note: Getting the effective source list above means that tokens matching the scheme-source grammar have already been normalized such that "http:"/"ws:" never appears without "https:"/"ws:" also appearing.

9. For each expression in schemes:

   1. If expression does not match "https:" or schemes does not contain "http:":

      1. If expression does not match "wss:" or schemes does not contain "ws:", append expression to intersection.

10. For each expression A in effective A:

    1. If expression A matches scheme-source grammar and schemes contains expression A, continue.

    2. For each expression B in effective B:

       1. If at least one of expression A and expression B does not match scheme-source or host-source grammar:

          1. If expression A matches keyword-source grammar and is an ASCII case-insensitive match for expression B, append expression A to intersection.

          2. If expression A matches nonce-source or hash-source grammar and is expression B, append expression A to intersection.

          3. Continue to the next expression B.

       2. If expression B’s scheme-part matches one of the elements in schemes, continue to the next expression B.

       3. If the result of executing § 4.2.1 What is an intersection of two expressions matching scheme-source or host-source grammar A and B? is not null given expression A and expression B, append the result to intersection.

11. Return intersection.

A = wss: http://example.com
B = https: wss: 'none'
intersection = wss: https://example.com

A = http://sub.a.com http://*.b.com
B = https://sub.a.com:* http://*.c.com
intersection = https://sub.a.com

A = 'unsafe-inline' http://example.com:443/page1/html 'nonce-abc'
B = 'unsafe-inline' https://example.com:443/ 'strict-dynamic' 'nonce-abc'
intersection = 'nonce-abc'

3.1.4. Intersection Helpers

3.1.4.1. Effective Directive Value

3.1.4.2. Effective Source List

https: wss: 'none' 'self'

http://example.com 'strict-dynamic' 'nonce-abc'

http://example.com 'strict-dynamic' 'nonce-abc'

3.1.4.3. Source Expression Similarity

A source expression (A) is said to be source-expression similar to another source expression (B) if the A is B, or if the relevant parts of their grammar match (for example, in the case of scheme-source expressions, the respective scheme-parts must scheme-part match in one direction or the other.

Note: This property is symmetric. That is if A is source-expression similar to B, then B will be source-expression similar to A.

A source expression has a wildcard host if the first character of the source expression’s host-part is an U+002A ASTERISK character (*).

A source expression has a wildcard port if the port-part of the source expression is an U+002A ASTERISK character (*).

1. If A’s grammar does not match B’s grammar, return "Not Similar".

2. If A matches the keyword-source, nonce-source, or hash-source grammar:

   1. If A is B, return "Similar".

   2. Return "Not Similar".

3. Let scheme A be A’s scheme-part, if present, and null otherwise.

4. Let scheme B be B’s scheme-part, if present, and null otherwise.

5. If the scheme A does not scheme-part match scheme B, and scheme B does not scheme-part match scheme A, return "Not Similar".

6. If A or B matches scheme-source grammar, return "Similar".

7. Let host A be A’s host-part, if present, and null otherwise.

8. Let host B be B’s host-part, if present, and null otherwise.

9. Let port A be A’s port-part, if present, and null otherwise.

10. Let port B be B’s port-part, if present, and null otherwise.

11. Let path A be A’s path-part, if present, and null otherwise.

12. Let path B be B’s path-part, if present, and null otherwise.

13. Return "Not Similar" if any of the following is true:

    1. Both A and B have a wildcard host, but host A is not an ASCII case-insensitive match to host B.

    2. At most one of A and B has a wildcard host, host A does not host-part match host B, and host B does not host-part match host A.

    3. Neither A nor B has a wildcard port, port A does not port-part match port B, and port B does not port-part match port A.

    4. path A does not path-part match path B, and path B does not path-part match path A.

14. Return "Similar".

A = 'nonce-ch4hvvbHDpv7xCSvXCs3BrNggHdTzxUA'
B = 'nonce-ch4hvvbHDpv7xCSvXCs3BrNggHdTzxUA'

A = https://inner.example.com/foo/
B = http://*.example.com/foo/bar/

A = http://*.example.com
B = https://inner.example.com:*

A = http://example.com:80/page1/html
B = https://example.com:443/

A = 'sha256-abc123'
B = 'sha512-cde456'

A = http://example.com:80
B = http://example.com:334

A = http://example.com/page.html
B = http://example.com/index.html

Move the remaining intersection algorithms into this section.

3.2. Subsumption

Move all the subsumption algorithms into this section.

4. Algorithms

4.1. Is response to request blocked by requiredCSP?

Given a response (response), a request (request), and a serialized CSP-or-null (requiredCSP), this algorithm returns "Allowed" or "Blocked" as appropriate:

1. Return "Allowed" if requiredCSP is null.

2. Let required policy be the result of parsing requiredCSP as "enforce".

3. If the § 4.2 Does response allow blanket enforcement of policy from request? algorithm returns "Allowed" when executed upon response and request, return "Allowed".

4. If the § 4.3 Does subsuming policy subsume policy list given their respective origins? algorithm returns "Subsumes" when executed upon required policy, request’s origin, the result of parsing response’s Content Security Policies, and response’s url’s origin, return "Allowed".

5. Return "Blocked".

4.2. Does response allow blanket enforcement of policy from request?

Given a response (response), and a request (request), this algorithm returns "Allowed" if the former allows the latter to enforce arbitrary policy, and "Not Allowed" otherwise:

1. If response’s url’s scheme is a local scheme, return "Allowed".

   Note: The local scheme responses already inherit their policy from the embedder, so we allow the embedder to tighten that policy via this embedding mechanism.

2. If response’s header list has a header named `Allow-CSP-From` (header):

   1. If header’s value is "*", return "Allowed".

   2. If request’s origin, serialized and UTF-8 encoded is header’s value, return "Allowed".

3. Return "Not Allowed".

4.2.1. What is an intersection of two expressions matching scheme-source or host-source grammar A and B?

Source expression is said to be an intersection of two other expressions matching scheme-source or host-source grammar A and B if it contains the more restrictive scheme-part, host-part, port-part, and path-part of the two.

A = https:
B = http:
Intersect = https:

A = http://*.example.com
B = https://example.com:*
Intersect = https://example.com:443

A = http://example.com:80/page1/html
B = https://example.com:443/
Intersect = null

A = https:
B = http://example.com
Intersect = https://example.com.

A = https://example.com:*
B = http://*.example.com/page.html
Intersect = https://example.com/page.html

Given two expressions matching the scheme-source or host-source grammar (A and B), return their intersection if A is source-expression similar to B. Otherwise, return null.

1. If A is not source-expression similar to B, return null.

2. Let source be an empty string.

3. Let scheme A be A’s scheme-part, if present, and null otherwise.

4. Let scheme B be B’s scheme-part, if present, and null otherwise.

5. Let more secure scheme B be true if scheme A does not scheme-part match scheme B, and false otherwise.

6. Append scheme A and ":" to source if scheme A is not null and more secure scheme B is false. Otherwise, append scheme B and ":" to source if scheme B is not null.

7. If both A and B match the scheme-source grammar, return source.

8. Append "//" to source if it is not empty.

9. Let host A be A’s host-part, if present, and null otherwise.

10. Let host B be B’s host-part, if present, and null otherwise.

11. If host A is not null:

    1. If host B is null, append host A to source. Continue to the next step in the main algorithm.

    2. If A doesn’t match the scheme-source grammar and doesn’t have a wildcard host, append host A to source.

    3. Otherwise, append host B to source.

12. If host A is null, append host B to source.

13. Let port A be A’s port-part, if present, and null otherwise.

14. Let port B be B’s port-part, if present, and null otherwise.

15. If port A is null, append ":" and port B to source if it is not null.

16. If port A is not null:

    1. If port B is null, append ":" and port A to source. Continue to the next step in the main algorithm.

    2. If A doesn’t have a wildcard port and more secure scheme B is false, append ":" and port A to source.

    3. Otherwise, append ":" and port B to source.

17. Let path A be A’s path-part, if present, and null otherwise.

18. Let path B be B’s path-part, if present, and null otherwise.

19. If path A is null, append path B to source if it is not null.

20. If path A is not null:

    1. If path B is null, return the result of appending path A to source.

    2. If path A path-part matches path B, append path A to source.

    3. Otherwise, append path B to source.

21. Return source.

4.2.2. Rewrite 'self' into a host-source expression for origin.

Given an origin (origin), this algorithm returns a host-source expression that has the same effect as 'self' for that origin:

1. If origin is an opaque origin, return the empty string.

2. Return the ASCII serialization of origin.

4.2.3. Does source expression A subsume source expression B?

Given two source expressions A and B, this algorithm returns "Subsumes" if A subsumes B, and returns "Does Not Subsume" otherwise.

1. Assert: Neither A nor B match the keyword-source grammar.

2. If both A and B match either host-source or scheme-source grammar:

   1. If Content Security Policy 3 § 6.7.2.9 scheme-part matching returns "Does Not Match" given A’s scheme-part (or null if A does not contain a scheme-part) and B’s scheme-part (or null if B does not contain a scheme-part), return "Does Not Subsume".

   2. If A or B matches the scheme-source grammar:

      1. If A matches the scheme-source grammar, return "Subsumes". Otherwise, return "Does Not Subsume".

   3. If B has a wildcard host:

      1. If A doesn’t have a wildcard host, return "Does not Subsume".

      2. Let remaining host B be the result of removing the leading ("*.") from B’s host-part.

      3. If Content Security Policy 3 § 6.7.2.10 host-part matching returns "Does Not Match" given A’s host-part and remaining host B, return "Does Not Subsume".

   4. If B doesn’t have a wildcard host and Content Security Policy 3 § 6.7.2.10 host-part matching returns "Does Not Match" given A’s host-part and B’s host-part, return "Does Not Subsume".

   5. If B has a wildcard port but A doesn’t have a wildcard port, return "Does Not Subsume".

   6. If B doesn’t have a wildcard port and Content Security Policy 3 § 6.7.2.11 port-part matching returns "Does Not Match" given A’s port-part (or null if A does not contain a port-part) and B’s port-part (or null if B does not contain a port-part), return "Does Not Subsume".

   7. If Content Security Policy 3 § 6.7.2.12 path-part matching returns "Does Not Match" given A’s path-part (or null if A does not contain a path-part) and B’s path-part (or null if B does not contain a path-part), return "Does Not Subsume".

   8. Return "Subsumes".

3. If both A and B match the hash-source grammar:

   1. If A is B, return "Subsumes". Otherwise, return "Does Not Subsume".

4. If both A and B match the nonce-source grammar:

   1. Return "Subsumes".

   Note: Nonce source matching is value-agnostic to prevent a malicious embedder from brute forcing the nonce value with an attack as described in § 6.1 Policy Leakage

Subsumption for nonces and hashes should be updated to account for more permissive sources (like 'self' or '*' combined with 'unsafe-inline') logically subsuming them.

5. Return "Does Not Subsume".

4.2.4. Does source list A subsume source listB given their respective origins and directive names?

Given a source list A with an origin (origin A) and a string (directive A), source list B with an origin (origin B) and a string (directive B), this algorithm returns "Subsumes" if A subsumes B, and returns "Does Not Subsume" otherwise.

A directive contains a given source expression if the expression is contained by its value.

1. If directive A is not an ASCII case-insensitive match to directive B, return "Does Not Subsume".

2. If A is empty or B is none, return "Subsumes".

3. If B is empty or A is none, return "Does Not Subsume".

4. If directive B is "script-src" and B contains a keyword-source expression "strict-dynamic" but A does not contain it, return "Does Not Subsume".

5. If directive B is "script-src" or "style-src":

   1. If B contains a keyword-source expression "unsafe-eval" but A does not contain it, return "Does Not Subsume".

   2. If B contains a keyword-source expression "unsafe-hashed-attributes" but A does not contain it, return "Does Not Subsume".

   3. Let type B be "script" if directive B is "script-src" and "style" otherwise. Similarly, let type A be "script" if directive A is "script-src" and "style" otherwise.

   4. If Content Security Policy 3 § 6.7.3.2 Does a source list allow all inline behavior for type? returns "Allows" given B with type B, but returns "Does Not Allow" given A with type A, return "Does Not Subsume".

6. Let list A and list B be empty lists.

7. For each expression A in A:

   1. If expression A is "self", append a host-source, returned by § 4.2.2 Rewrite 'self' into a host-source expression for origin. given origin A to list A.

   2. If expression A matches the U+002A ASTERISK character (*), append to list A the following scheme-source expressions: "ftp:", "http:", "https:", "ws:", "wss:", and origin A’s scheme.

      1. If directive A is either "img-src" or "media-src", append a scheme-source expression "data:" to list A.

      2. If directive A is "media-src", append a scheme-source expression "blob:" to list A.

      3. Continue to the next expression A.

   3. If expression A does not match keyword-source grammar, append expression A to list A.

8. For each expression B in B:

   1. If expression B is "self", append a host-source, returned by § 4.2.2 Rewrite 'self' into a host-source expression for origin. given origin B to list B.

   2. If expression B matches the U+002A ASTERISK character (*), append to list B the following scheme-source expressions: "ftp:", "http:", "https:", "ws:", "wss:", and origin B’s scheme.

      1. If directive B is either "img-src" or "media-src", append a scheme-source expression "data:" to list B.

      2. If directive B is "media-src", append a scheme-source expression "blob:" to list B.

      3. Continue to the next expression B.

   3. If expression B does not match keyword-source grammar, append expression B to list B.

9. If list B is empty, return "Subsumes".

10. If list A is empty, return "Does Not Subsume".

11. For each expression B in list B:

    1. If expression B matches the hash-source gramar, or nonce-source grammar, continue to the next expression unless directive A is "script-src" or "style-src".

    2. Let found match be false.

    3. For each expression A in list A:

       1. If § 4.2.3 Does source expression A subsume source expression B? returns "Subsumes" given expression A and expression B, set found match to true. Break out of this inner loop.

    4. If found match is false, return "Does Not Subsume".

12. Return "Subsumes".

A = "http://example.com 'sha256-xzi4zkCjuC8'"
B = "http://example.com"

A = "https://example.com 'sha256-xzi4zkCjuC8'"
B = "http://example.com"

A = "http://example.com 'sha256-xzi4zkCjuC8'"
B = "http://example.com 'unsafe-inline'"

A = "http://example.com 'sha256-xzi4zkCjuC8' 'strict-dynamic'"
B = "http://example.com 'unsafe-inline' 'strict-dynamic'"

4.2.5. Does content security policy object A subsume content security policy object B given their respective origins?

Given a content security policy object A with an origin (origin A) and a content security policy object B with an origin (origin B), this algorithm returns "Subsumes" if A subsumes B, and returns "Does Not Subsume" otherwise.

1. If A’s directive set is empty, return "Subsumes".

2. For each directive A in A’s directive set:

   1. Let directive name be directive A’s name.

   2. If directive name is "default-src", "report-uri", "report-to", continue.

   3. Let effective directive A be the effective directive value for directive name and A.

   4. Let effective directive B be the effective directive value for directive name and B.

   5. If effective directive A is null, continue.

   6. If effective directive B is null, return "Does Not Subsume".

   7. If directive A’s name is "frame-ancestors":

      1. If effective directive B is « "'none'" », continue.

      2. If effective directive A is « "'none'" », return "Does Not Subsume".

      3. For each expression B in effective directive B:

         1. Let found match be false.

         2. For each expression A in effective directive A:

            1. If § 4.2.3 Does source expression A subsume source expression B? returns "Subsumes" given expression A and expression B, set found match to true. Break out of this inner loop.

         3. If found match is false, return "Does Not Subsume".

   8. If directive A’s name is "plugin-types":

      1. For each type B in effective directive B:

         1. If effective directive A does not contain type B, return "Does Not Subsume".

   9. If directive A’s name is "sandbox":

      1. Let flags A be the result of parsing a sandboxing directive given effective directive A.

      2. Let flags B be the result of parsing a sandboxing directive given effective directive B.

      3. For each flag in flags A:

         1. If flags B does not contain flag, return "Does Not Subsume".

      Note: A policy $A$ subsumes $B$ if $B$ is more restrictive. For sandbox flags, this means every permission allowed by $A$ must also be allowed by $B$. If $B$ omits a flag that $A$ includes, $B$ is not at least as restrictive as $A$ for that specific permission.

   10. If directive A’s name is "disown-opener", continue.

   11. Otherwise:

       1. If the result of executing § 4.2.4 Does source list A subsume source listB given their respective origins and directive names? is "Does Not Subsume" given effective directive A, origin A, directive name, effective directive B, origin B, and directive name, return "Does Not Subsume".

   3. Return "Subsumes".

4.3. Does subsuming policy subsume policy list given their respective origins?

Given a content security policy object subsuming policy with an origin (subsuming origin) and a list of content security policy object objects policy list with an origin (origin), this algorithm returns "Subsumes" if subsuming policy subsumes policy list, and returns "Does Not Subsume" otherwise.

1. If subsuming policy is null, return "Subsumes".

2. If subsuming policy’s disposition is "report", return "Subsumes".

3. If subsuming policy’s directive set is empty, return "Subsumes".

4. If policy list is is empty or null, return "Does Not Subsume".

5. Let effective policy the result of executing § 3.1.1 CSP List intersection given policy list and origin.

6. Return the result of executing § 4.2.5 Does content security policy object A subsume content security policy object B given their respective origins? given subsuming policy, subsuming origin, effective policy, and origin.

5. Security Considerations

Define an explicit threat model covering embedder protection, embedee opt-in rationale, and privacy concerns.

5.1. Policy Enforcement

Embedded documents should be careful to evaluate the proposed Content Security Policy, and not simply to reflect whatever policy an embedder suggests. Doing so may enable a clever attacker to selectively disable pieces of a website’s code which are essential for its own protection.

In particular, documents which do not expect to be embedded should continue to respond to any such request with a Content Security Policy containing an appropriate frame-ancestors directive.

5.2. Header Injection

Spell out the concerns Mario raised in the thread around https://twitter.com/0x6D6172696F/status/810066803653308416.

5.3. Header Reflection

Spell out the concerns Mario raised in the thread around https://twitter.com/0x6D6172696F/status/810066803653308416.

5.4. Header Length

This feature allows an embedder to control the value of the `Sec-Required-CSP` HTTP header for cross-origin embedded document requests. If the server enforces a limit on the length of HTTP headers, this can cause a network error. This can be abused by an attacker to force a cache invalidation, see https://xsleaks.dev/docs/attacks/cache-probing/#cache-probing-with-error-events. Because of this, we limit the maximum length of valid csp attributes to 4 KB.

6. Privacy Considerations

6.1. Policy Leakage

The enforcement mechanism allows a malicious embedder to read a page’s policy cross-origin by brute-forcing its constraints. This could leak interesting data about the page or the user loading the page if the policy contains secret tokens or usernames.

Again, the best defense here is to control the contexts allowed to embed a given resource via an appropriate frame-ancestors directive.

6.2. Data Exfiltration

This feature allows an embedder to send information to a third-party endpoint via the `Sec-Required-CSP` HTTP header. This doesn’t seem to expose any information that couldn’t be tunneled in the HTTP request itself (via GET parameters, etc), and embedders remain in control over the endpoints to which such requests may be made by enforcing a Content Security Policy with an appropriate child-src directive.

7. Authoring Considerations

7.1. Requiring 'self'

When processing a required CSP, the keyword 'self' refers to the origin of the URL being loaded into the child navigable, not to the origin of the document which required the policy.

<iframe src="https://advertisements-r-us.example.com/ad1.cfm"
        csp="script-src 'self'">
</iframe>

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

Content-Security-Policy: script-src "https://example.com/"

8. IANA Considerations

The permanent message header field registry should be updated with the following registration for the `Sec-Required-CSP` header: [RFC3864]

Header field name

Sec-Required-CSP

Applicable protocol

http

Status

standard

Author/Change controller

W3C

Specification document

This specification (See § 2.2 The Sec-Required-CSP HTTP Request Header)

Likewise, the registry should be updated with the following registration for the `Allow-CSP-From` header: [RFC3864]

Header field name

Allow-CSP-From

Applicable protocol

http

Status

standard

Author/Change controller

W3C

Specification document

This specification (See § 2.3 The Allow-CSP-From HTTP Response Header)