Source: https://w3c.github.io/webappsec-cspee/
Timestamp: 2019-04-20 20:22:24+00:00

Document:
Copyright © 2018 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and document use rules apply.
4.1 Is response to request blocked by context’s required CSP?
4.2 Does response allow blanket enforcment of policy from request?
4.2.1 What is an intersection of two expressions matching scheme-source or host-source grammar A and B?
4.2.2 Rewrite 'self' into a host-source expression for origin.
4.2.3 Does source expression A subsume source expression B?
4.2.4 Does source list A subsume source listB given their respective origins and directive names?
4.2.5 Does policy A subsume policy B given their respective origins?
4.3 Does subsuming policy subsume policy list given their respective origins?
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.
Since the policy asserted by the response allows strictly fewer requests than the policy required by the request, the frame loads successfully.
The "," in the Content-Security-Policy header’s value splits the string into two serialized policies, each of which is enforced. The user agent verifies that one of the policies delivered with the response matches the requirement, and since additional policies can only make the effective policy for the page more restrictive, allows the frame to load successfully.
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.
That attribute’s value will be sent along with any navigation request that targets the iframe's nested browsing context in a Sec-Required-CSP HTTP request header. This header is described in more detail in §2.2 The Sec-Required-CSP HTTP Request Header.
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 context’s required CSP?.
value is not the empty string.
value matches the serialized-policy ABNF grammar defined in [CSP].
element’s node document's browsing context's required CSP is null.
The result of parsing value as "enforce" is subsumed by element’s node document's browsing context's required CSP.
Note: We consider the last item valid even though it doesn’t express a meaningful policy in order to remain forward-compatible with future CSP syntax.
Note: We need to be careful about the values we allow in the csp attribute, as its contents will end up reflected as an HTTP request header. This concern is discussed in a little more detail in §5.4 Header Injection.
The csp IDL attribute must reflect the element’s csp content attribute.
Upstream this to all the HTMLs.
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.5 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.
If request is not a navigation request, return.
Let requirement be request’s client’s responsible browsing context’s required CSP.
If requirement is null, return.
Assert: requirement is a serialized CSP, matching the serialized-policy grammar defined in [CSP].
Append a header named "Sec-Required-CSP" with a value of requirement to request’s header list.
iframe elements have a csp attribute, defined in §2.1 <iframe>'s csp attribute.
Each browsing context has a required CSP, defined in §2.4.1 Browsing Context’s Required CSP.
Upstream this to WHATWG’s HTML.
The §4.1 Is response to request blocked by context’s required CSP? algorithm returns "Blocked" when executed upon response, request, and browsingContext.
Each browsing context has a required CSP, which is either null or a serialized CSP. The value is set during the navigate algorithm, and will not change until the browsing context’s active document changes.
If context’s browsing context container has an csp content attribute with a valid attribute value (value), set context’s required CSP to value and return.
Set context’s required CSP to the value of context’s parent browsing context’s required CSP.
Set context’s required CSP to null.
Upstream a hook to HTML.
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.
A policy (A) is said to subsume another policy (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 policy (A) is said to subsume a CSP list if A subsumes their intersection.
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.
Let result be a policy object with an empty directive set and a disposition of "enforce".
If policy’s disposition is "report", continue.
Set result to the intersection of result and policy for origin.
Each policy specified in the initial list subsumes the intersection.
Assert: A and B both have a disposition of "enforce".
If A’s directive set is empty, return B.
If B’s directive set is empty, return A.
Let policy be a new policy with an empty directive set, and a disposition "enforce".
Let directive names be an empty set.
Append directive’s name to directive names.
If directive name is "report-uri", "report-to", continue.
Let directive A be the effective directive value for directive name and A.
Let directive B be the effective directive value for directive name and B.
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.
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.
append a directive to policy’s directive set.
Let directive value be the intersection of directive A’s value, directive B’s value, directive name, and origin.
Append directive to policy’s directive set.
Both of the given policies subsume the intersection. For example, the intersection’s "script-src http://example.com/" is subsumed by the first policy’s "default-src 'self' http://example.com http://example.net" and the second policy’s "script-src http://example.com/".
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' ».
Let effective A be the effective source list for A, name, and origin.
Let effective B be the effective source list for B, name, and origin.
If either effective A or effective B is « 'none' », return « 'none' ».
If effective A is empty, return effective B.
If effective B is empty, return effective A.
6 Let schemes be an empty set.
Let intersection be an empty source list.
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.
If expression does not match "wss:" or schemes does not contain "ws:", append expression to intersection.
If expression A matches scheme-source grammar and schemes contains expression A, continue.
If expression A matches keyword-source grammar and is an ASCII case-insensitive match for expression B, append expression A to intersection.
If expression A matches nonce-source or hash-source grammar and is a case-sensitive match for expression B, append expression A to intersection.
Continue to the next expression B.
If expression B’s scheme-part matches one of the elements in schemes, continue to the next expression B.
If expression B matches host-source grammar and 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.
If the result of executing §4.2.4 Does source list A subsume source listB given their respective origins and directive names? is "Subsumes" given expression B and expression A, append expression A to intersection. Continue to the next expression A.
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, set match to the result.
If match is not null, append match to intersection.
In these cases, intersection is an intersection for A and B.
The expression "wss:" is present in both policies, so it is present in their intersection. Similarly, "http://example.com" is present in the intersection because it is the only expression subsumed by both "http://example.com" and "https:". Note that "'none'"" is ignored, as it is not the only token in B.
Only two sources are similar: "http://*.a.com" in A is similar to "https://a.com:*" in B so the intersection of the two source lists is "https://a.com".
Since "strict-dynamic" honors only nonce-source and hash-source expressions, B is effectively "'strict-dynamic' 'nonce-abc'". That is why the intersection is "'nonce-abc'".
If policy’s directive set contains a directive whose name is name, return that directive’s value.
If policy’s directive set contains a directive whose name is "default-src", return that directive’s value.
If policy’s directive set contains a directive whose name is "child-src", return that directive’s value.
If list is empty or « 'none' », return « 'none' ».
Let result be an empty source list.
Append the result of executing §4.2.2 Rewrite 'self' into a host-source expression for origin. given origin to result.
If expression matches the keyword-source grammar, and name is not "script-src" or "style-src", continue.
expression is "'strict-dynamic'" and name is not "script-src"
expression matches either the nonce-source or hash-source grammar, and name is not "script-src" or "style-src"
expression is "'unsafe-inline'", name is "script-src, and list contains one or more tokens that match one of the nonce-source grammar, the hash-source grammar, or "'strict-dynamic'"
expression matches either the host-source or scheme-source grammar, name is "script-src", amd list contains the token "'strict-dynamic'"
Append the concatenation of origin’s scheme and ":" to result.
If expression is "http:", append "https:" to result.
If expression is "ws:", append "wss:" to result.
If expression’s scheme-part is "http", append the result of concatenating "https://", expression’s host-part, expression’s port-part, and expression’s path-part to result.
If expression’s scheme-part is "ws", append the result of concatenating "wss://", expression’s host-part, expression’s port-part, and expression’s path-part to result.
If result is empty or « 'strict-dynamic' », return « 'none' ».
The effective source list is "http: wss: https://example.test/". Note that "'none'" is not part of the effective source list because it has no effect when it is not the only source.
The effective source list is "http://example.com 'nonce-abc'" since "'strict-dynamic'" is ignored in non-"script-src" directives.
The effective source list is "'strict-dynamic' 'nonce-abc'" since "'strict-dynamic'" in "script-src" case does not honor host and scheme source expressions.
A source expression (A) is said to be source-expression similar to another source expression (B) if the two expressions are case-sensitive matches, 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 (*).
If A’s grammar does not match B’s grammar, return "Not Similar".
If A is a case-sensitive match to B, return "Similar".
Let scheme A be A’s scheme-part, if present, and null otherwise.
Let scheme B be B’s scheme-part, if present, and null otherwise.
If the scheme A does not scheme-part match scheme B, and scheme B does not scheme-part match scheme A, return "Not Similar".
If A or B matches scheme-source grammar, return "Similar".
Let host A be A’s host-part, if present, and null otherwise.
Let host B be B’s host-part, if present, and null otherwise.
Let port A be A’s port-part, if present, and null otherwise.
Let port B be B’s port-part, if present, and null otherwise.
Let path A be A’s path-part, if present, and null otherwise.
Let path B be B’s path-part, if present, and null otherwise.
Both A and B have a wildcard host, but host A is not an ASCII case-insensitive match to host B.
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.
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.
path A does not path-part match path B, and path B does not path-part match path A.
Since both A and B match the nonce-source grammar and A is a case-sensitive match for B, A is similar to B.
Since A has a wildcard host, it matches any subdomain which in this case is "inner" so that A is similar to B.
Even though A and B’s ports are different, A and B are similar because "http" matches both "http" and a more secure variant "https".
In both sources specified ports are defalt ports for the respective schemes and B’s path would match any path, A is similar to B.
Even though both A and B match the hash-source grammar, A is not a case-sensitive match for B because the hashes don’t match.
In this case, ports of A and B do not match so that the two sources are not similar .
The two sources are not similar because their paths do not match.
Move the remaining intersection algorithms into this section.
Move all the subsumption algorithms into this section.
4.1. Is response to request blocked by context’s required CSP?
context is not a nested browsing context.
context’s required CSP is null.
Let required policy be the result of executing Content Security Policy Level 3 §parse-serialized-policy on context’s required CSP and "enforce".
Append required policy to response’s CSP list.
Assert: context is a nested browsing context, and response is a cross-origin, network schemed resource.
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, response’s CSP list, and response’s url’s origin, return "Allowed".
4.2. Does response allow blanket enforcment of policy from request?
If response’s url’s scheme is a local scheme, return "Allowed".
Note: The embedder has direct access to same-origin responses, so if it wishes to enforce a policy on that same-origin response, we simply do so.
If response’s url’s origin is the same as request’s origin, return "Allowed".
Note: Likewise, local scheme responses already inherit their policy from the embedder, so we allow the embedder to tighten that policy via this embedding mechanism.
If header’s value is "*", return "Allowed".
If request’s origin, serialized and UTF-8 encoded is header’s value, return "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.
In these cases, Intersect is an intersection for A and B.
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.
If A is not source-expression similar to B, return null.
Let source be an empty string.
Let more secure scheme B be true if scheme A does not scheme-part match scheme B, and false otherwise.
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.
If both A and B match the scheme-source grammar, return source.
Append "//" to source if it is not empty.
If host B is null, append host A to source. Continue to the next step in the main algorithm.
If A doesn’t match the scheme-source grammar and doesn’t have a wildcard host, append host A to source.
Otherwise, append host B to source.
If host A is null, append host B to source.
If port A is null, append ":" and port B to source if it is not null.
If port B is null, append ":" and port A to source. Continue to the next step in the main algorithm.
If A doesn’t have a wildcard port and more secure scheme B is false, append ":" and port A to source.
Otherwise, append ":" and port B to source.
If path A is null, append path B to source if it is not null.
If path B is null, return the result of appending path A to source.
If path A path-part matches path B, append path A to source.
Otherwise, append path B to source.
4.2.2. Rewrite 'self' into a host-source expression for origin.
If origin is an opaque origin, return the empty string.
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.
Assert: Neither A nor B match the keyword-source grammar.
If Content Security Policy Level 3 §match-schemes 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".
If A matches the scheme-source grammar, return "Subsumes". Otherwise, return "Does Not Subsume".
If A doesn’t have a wildcard host, return "Does not Subsume".
Let remaining host B be the result of removing the leading ("*.") from B’s host-part.
If Content Security Policy Level 3 §match-hosts returns "Does Not Match" given A’s host-part and remaining host B, return "Does Not Subsume".
If B doesn’t have a wildcard host and Content Security Policy Level 3 §match-hosts returns "Does Not Match" given A’s host-part and B’s host-part, return "Does Not Subsume".
If A has a wildcard port but B doesn’t have a wildcard port, return "Does Not Subsume".
If A doesn’t have a wildcard port and Content Security Policy Level 3 §match-ports 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".
If Content Security Policy Level 3 §match-paths 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".
If A is a case-sensitive match to B, return "Subsumes". Otherwise, 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.
If directive A is not an ASCII case-insensitive match to directive B, return "Does Not Subsume".
If A is empty or B is none, return "Subsumes".
If B is empty or A is none, return "Does Not Subsume".
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".
If B contains a keyword-source expression "unsafe-eval" but A does not contain it, return "Does Not Subsume".
If B contains a keyword-source expression "unsafe-hashed-attributes" but A does not contain it, return "Does Not Subsume".
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.
If Content Security Policy Level 3 §allow-all-inline returns "Allows" given B with type B, but returns "Does Not Allow" given A with type A, return "Does Not Subsume".
Let list A and list B be empty lists.
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.
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.
If directive A is either "img-src" or "media-src", append a scheme-source expression "data:" to list A.
If directive A is "media-src", append a scheme-source expression "blob:" to list A.
Continue to the next expression A.
If expression A does not match keyword-source grammar, append expression A to list A.
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.
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.
If directive B is either "img-src" or "media-src", append a scheme-source expression "data:" to list B.
If directive B is "media-src", append a scheme-source expression "blob:" to list B.
If expression B does not match keyword-source grammar, append expression B to list B.
If list B is empty, return "Subsumes".
If list A is empty, return "Does Not Subsume".
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".
Let found match be false.
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.
If found match is false, return "Does Not Subsume".
Since B does not allow hash-source expressions, but its value is found in A, A subsumes B. It is, however, not true that B subsumes A.
In this case, A does not subsume B since "https://example.com" does not subsume "http://example.com".
Since B allows all inline behavior, but A does not, A doesn’t subsume B.
A = "http://example.com 'sha256-xzi4zkCjuC8' 'strict-dynamic'"
B = "http://example.com 'unsafe-inline' 'strict-dynamic'"
Neither A nor B allows all inline behavior. In this case, A subsumes B.
4.2.5. Does policy A subsume policy B given their respective origins?
Given a policy A with an origin (origin A) and a policy B with an origin (origin B), this algorithm returns "Subsumes" if A subsumes B, and returns "Does Not Subsume" otherwise.
If A’s directive set is empty, return "Subsumes".
Let directive name be directive A’s name.
If directive name is "default-src", "report-uri", "report-to", continue.
Let effective directive A be the effective directive value for directive name and A.
Let effective directive B be the effective directive value for directive name and B.
If effective directive A is null, continue.
If effective directive B is null, return "Does Not Subsume".
If directive A’s name is "disown-opener", continue.
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".
4.3. Does subsuming policy subsume policy list given their respective origins?
Given a policy subsuming policy with an origin (subsuming origin) and a list of policy objects policy list with an origin (origin), this algorithm returns "Subsumes" if subsuming policy subsumes policy list, and returns "Does Not Subsume" otherwise.
If subsuming policy is null, return "Subsumes".
If subsuming policy’s disposition is "report", return "Subsumes".
If subsuming policy’s directive set is empty, return "Subsumes".
If policy list is is empty or null, return "Does Not Subsume".
Let effective policy the result of executing §3.1.1 CSP List intersection given policy list and origin.
Return the result of executing §4.2.5 Does policy A subsume policy B given their respective origins? given subsuming policy, subsuming origin, effective policy, and origin.
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.
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.
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.
Spell out the concerns Mario raised in the thread around https://twitter.com/0x6D6172696F/status/810066803653308416.
When processing a browsing context’s required CSP, the keyword 'self' refers to the origin of the URL being loaded into the nested browsing context, not to the origin of the document in the source browsing context.
Then this iframe element will be loaded.
Then this iframe element will not be loaded.

References: §2
 §2
 §2
 §3
 §2
 §4
 §5
 §5
 §2
 §2
 §4
 §3
 §3
 §4
 §4
 §4
 §4
 §4
 §4
 §4
 §4
 §4
 §3
 §4