Source: https://w3c.github.io/webappsec-csp/embedded/
Timestamp: 2017-03-23 12:11:45
Document Index: 266314210

Matched Legal Cases: ['§2', '§2', '§3', '§2', '§4', '§5', '§5', '§2', '§4', '§3', '§3', '§4', '§4', '§4', '§4', '§4', '§4', '§4', '§4', '§4', '§3', '§4', '§4', '§3', '§4', '§3', '§3', '§3', '§2', '§2', '§4', '§4', '§4']

Editor’s Draft, 21 December 2016
This document defines a mechanism by which a web page can embed a nested
browsing context if and only if it agrees to enforce a particular set of
restrictions upon itself.
please put the text “csp-embedded-enforcement” in the subject,
“[csp-embedded-enforcement] …summary of comment…” This document was produced by the Web Application Security Working Group. This document was produced by a group operating under
3.1.1 Policy List intersection
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 Is an expression matching scheme-source or host-source grammar A similar to an expression matching scheme-source or host-source grammar B? 4.2.2 What is an intersection of two expressions matching scheme-source or host-source grammar A and B? 4.2.3 Rewrite 'self' into a host-source expression for origin. 4.2.4 Does source expression A subsume source expression B? 4.2.5 Does source list A subsume source listB given their
respective origins and directive names? 4.2.6 Does policy A subsume policy B given their respective origins? 4.3 Does subsuming policy subsume policy list given their respective origins? 5 Security and Privacy Considerations
6.1 Requiring 'self' 7 IANA Considerations
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 (Embedding-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.
MegaCorp Inc. wishes to ensure that the advertisements that run on its
various publications are locked down to include script from trusted origins
that have been audited for safety. They can do so by including the
advertisement via an iframe element with a csp attribute: &lt;iframe src="https://advertisements-r-us.example.com/ad1.cfm"
This will generate a request to advertisements-r-us.example.com that has
an Embedding-CSP header, as follows:
The advertisement server parses this request header, decides that it’s acceptable, and adds a
header to the response, informing the user agent that it will adhere to the restrictions imposed
by its embedder (https://example.com):
The advertisement server in the example above could also accept the restrictions by emitting its
own Content-Security-Policy header that’s at least as strong as the policy
which the embedder requires. For example, it might wish to ensure that no plugins are loaded,
regardless of what the embedder allows. It can do so by emitting a policy that includes the
embedder’s restrictions, and adds more on top: HTTP/1.1 200 OK
Since the policy asserted by the response allows strictly fewer requests than the policy
required by the request, the frame loads successfully.
Note that the server could also deliver two policies, one which mirrors the restrictions of the
embedder exactly, another which tightens them:
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.
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:
That attribute’s value will be sent along with any navigation request that targets
the iframe's nested browsing context in an Embedding-CSP HTTP request header. This header is described in more detail in §2.2 The Embedding-CSP HTTP Request Header.
Rename this? Required-CSP, perhaps, to match the rest of the spec?
The server can examine the Embedding-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?.
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
&lt;iframe src="https://embedee.example.com/" csp="object-src 'none'">
A string (value) is a valid attribute value for a given element (element)'s csp content attribute if all of the
value matches the serialized-policy ABNF grammar defined in [CSP3].
element’s node document’s browsing context’s required CSP is null, or the result of parsing value as "enforce" is subsumed by element’s node document’s browsing
context’s required CSP.
The following strings are valid values for the csp attribute, as they’re valid CSP
grammar: script-src 'none'
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.
The following, on the other hand, do not match the CSP syntax, and would not be considered valid
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.
iframe's csp content attribute has a corresponding IDL attribute, defined
by the following WebIDL grammar [WEBIDL]:
The HTMLIFrameElement csp IDL attribute’s getter will run the
following steps on a given element: Let value be the value of element’s csp content attribute.
If value is a valid attribute value for element, return value.
The HTMLIFrameElement csp IDL attribute’s setter will run the
following steps on a given element for a given value: If value is a valid attribute value for element, set element’s csp content attribute to the empty string and return.
Set element’s csp content attribute to the empty string.
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 an
"Embedding-CSP" HTTP request header. The header’s value is
represented by the following ABNF [RFC5234]:
A user agent MUST NOT send more than one HTTP response header field named "Embedding-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.
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):
To set the Embedding-CSP header for a
given request (request), run the following steps: If request is not a navigation request, return.
Assert: requirement is a serialized CSP, matching the serialized-policy grammar defined in [CSP3].
Append a header named "Embedding-CSP" with a
value of requirement to request’s header list.
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
W3C’s HTML’s navigation algorithm is wildly divergent from WHATWG’s at
this point. Upstream something to that document once things are reconciled. <https://github.com/w3c/html/issues/584>
The §4.1 Is response to request blocked by context’s required CSP? algorithm returns "Blocked" when executed
upon response, request, and browsingContext.
W3C’s HTML is not based on Fetch, and does not have
a process a navigate response algorithm into which to hook. <https://github.com/w3c/html/issues/584>
Set request's
"Embedding-CSP" header.
a process a navigate fetch algorithm into which to hook. <https://github.com/w3c/html/issues/584>
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.
To set the required CSP for a given browsing context (context),
run the following steps: If context is a nested browsing context:
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.
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
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 Content Security Policy Level 3 §multiple-policies. Here, we’ll talk about the combined effect of a list of policy objects as their intersection. The details of
determining that are spelled out in §3.1 Intersection.
A policy (A) is said to subsume a list of policy objects if A subsumes their intersection.
3.1.1. Policy List intersection
Given a list of policies (policy list) and an origin (origin),
the intersection of policy list for origin is a single 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.
Let intersection be a policy object with an empty directive set and a disposition of "enforce".
Let result be the intersection
of intersection and policy for origin
Set intersection to result.
The intersection of the policies created by parsing each item in the following list of serialized CSPs: «
Given two policies (A and B), and an origin (origin), the intersection of A and B for origin is a single policy representing their net effect, produced by the
following algorithm: Assert: A and B both have a disposition of "enforce".
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.
Let directive value be the intersection of directive A’s value, directive B’s value, directive
name, and origin.
The intersection of the policies obtained by parsing the following serialized CSPs: "default-src 'self' http://example.com http://example.net;
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/".
Given two source lists (A and B), their name (name), and
their origin (origin), the intersection of A and B for name and origin is a source list representing their net effect. If no such source
expressions exist because the lists contain only divergent expressions (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, directive A, and origin.
Let effective B be the effective source list for B, directive B, and origin.
If either effective A or effective B is « 'none' »,
return « 'none' ».
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 A matches scheme-source grammar
and schemes contains expression A, continue.
If at least one of expression A and expression B does not
match scheme-source or host-source grammar:
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.2 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.5 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.2 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
In these cases, intersection is an intersection for A and B. A = wss: http://example.com
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".
Given a string (name) and a policy (policy), the effective directive value for name and policy is the value resulting from running the following steps: Switch on name and execute the associated steps:
If policy’s directive set contains a directive whose name is name, return thatdirective’s value.
If policy’s directive set contains a directive whose name is "default-src", return thatdirective’s value.
If policy’s directive set contains a directive whose name is "child-src", return thatdirective’s value.
Given a source list (list), a string (name), and an origin (origin), the effective source list for list, name, and origin is a simplification of list that expands complex tokens like 'self' and *, and removes ineffective, obviated, or invalid
tokens (for instance, 'unsafe-inline' in the presence of a nonce). The result
of running the following steps will generally be more verbose than list, but will be
significantly simpler to compare: If list is empty or « 'none' », return « 'none' ».
Append the result of executing §4.2.3 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 matches either the nonce-source or hash-source grammar, and name is not "script-src" or
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'"
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.
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.
4.1. Is response to request blocked by context’s required CSP? Given a response (response), a request (request), and a browsing context (context), this algorithm returns "Allowed" or
"Blocked" as appropriate:
Let embedding policy be the result of executing Content Security Policy Level 3 §parse-serialized-policy on context’s required CSP and
"enforce".
Append embedding policy to response’s CSP
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 embedding 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? 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:
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 request’s origin, serialized and UTF-8
encoded is header’s value, return "Allowed".
4.2.1. Is an expression matching scheme-source or host-source grammar A similar to an expression matching scheme-source or host-source grammar B? Given two expressions matching the scheme-source or host-source grammar (A and B), return "Similar" if A is similar to B. Otherwise, return "Not Similar".
A and B are said to be similar if their
parts individually match, that is scheme-part, host-part, port-part, and path-part.
NOTE: This property is symmetric. That is if A is similar to B, it must be that B is similar to A.
Cases when A is similar to B. A = https://inner.example.com/foo/
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.
Cases when A is not similar to B.
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 beucase their
paths do not match.
If the result of executing Content Security Policy Level 3 §match-schemes returns
"Does Not Match" given scheme A and scheme B, and the result of executing Content Security Policy Level 3 §match-schemes on scheme B and scheme A is "Does Not Match", return "Not Similar".
If A or B matches scheme-source grammar,
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, the result of executing Content Security Policy Level 3 §match-hosts is "Does Not Match" given host A and host B, and the result of executing Content Security Policy Level 3 §match-hosts on host B and host A is also "Does Not Match".
Neither A nor B has a wildcard port,
the result of executing Content Security Policy Level 3 §match-ports is "Does Not Match"
given port A and port B, and the result of executing Content Security Policy Level 3 §match-ports given port B and port A is also "Does Not Match".
The result of executing Content Security Policy Level 3 §match-paths is "Does Not Match"
given path A and path B and the result of executing Content Security Policy Level 3 §match-paths given path B and path A is also "Does Not Match".
4.2.2. 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. A = https:
Given two expressions matching the scheme-source or host-source grammar (A and B), return their intersection if A is similar to B. Otherwise, return null.
If the result of executing §4.2.1 Is an expression matching scheme-source or host-source grammar A similar to an expression matching scheme-source or host-source grammar B? on A and B is "Not Similar", return null.
Let more secure scheme B be true if the result of executing Content Security Policy Level 3 §match-schemes is "Does Not match" given scheme A and 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,
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.
If port A is null, append ":" and port B to source if it is
If port B is null, append ":" and port A to source.
If path B is null, append path A to source.
If the result of executing Content Security Policy Level 3 §match-paths on path A and path B is "Does Not Match", append path A to source.
4.2.3. 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:
serialization of origin.
4.2.4. 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.
If A matches the scheme-source grammar, return
"Subsumes". Otherwise, return "Does Not Subsume".
Let remaining host B be the result of removing the leading
("*.") from B’s host-part.
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,
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 A is a case-sensitive match to B, return "Subsumes".
Otherwise, return "Does Not Subsume".
4.2.5. 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
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 expression A is "self", append a host-source,
returned by §4.2.3 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 <a grammar>scheme-source</a> expression "data:" to |list A|.</p> </li><li data-md><p>If |directive A| is "media-src", append a scheme-source expression "blob:" to list A.
If expression B is "self", append a host-source,
returned by §4.2.3 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 <a grammar>scheme-source</a> expression "data:" to |list B|.</p> </li><li data-md><p>If |directive B| is "media-src", append a scheme-source expression "blob:" to list B.
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".
If §4.2.4 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.
Let directive A and directive B be "script-src". Consider
the following examples: A = "http://example.com 'sha256-xzi4zkCjuC8'"
Since B does not allow hash-source expressions, but its
value is found in A, A subsumes B. It is, however, not true that A subsumes B.
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.
Neither A nor B allows all inline behavior.
In this case, A subsumes B.
4.2.6. 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"
If A’s directive set is empty,
"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
If subsuming policy’s disposition is "report",
If policy list is is empty or null, return
Let effective policy the result of executing §3.1.1 Policy List intersection given policy list and origin.
Return the result of executing §4.2.6 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 Embedding-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.
6.1. Requiring 'self' 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
MegaCorp Inc. requires a policy containing 'self' on their page at https://example.com/page.html: &lt;iframe src="https://advertisements-r-us.example.com/ad1.cfm"
with the following registration for the Embedding-CSP header: [RFC3864]
Likewise, the registry should be updated with the following registration
for the Allow-CSP-From header: [RFC3864]
contains, in §4.2.5
dfn for policy, in §3
dfn for source expression, in §4.2.2
intersection of policy list for origin, in §3.1.1
intersection of two policies, in §3.1.2
intersection of two source lists, in §3.1.3
set-embedding-csp, in §2.2
set the Embedding-CSP header, in §2.2
similar, in §4.2.1
wildcard host, in §4.2.1
wildcard port, in §4.2.1
Rename this? Required-CSP, perhaps, to match the rest of the spec? ↵ Upstream this to all the HTMLs. ↵ Upstream this to WHATWG’s HTML. ↵ W3C’s HTML’s navigation algorithm is wildly divergent from WHATWG’s at
this point. Upstream something to that document once things are reconciled. <https://github.com/w3c/html/issues/584> ↵ Upstream this to WHATWG’s HTML. ↵ W3C’s HTML is not based on Fetch, and does not have
a process a navigate response algorithm into which to hook. <https://github.com/w3c/html/issues/584> ↵ Upstream this to WHATWG’s HTML. ↵ W3C’s HTML is not based on Fetch, and does not have
a process a navigate fetch algorithm into which to hook. <https://github.com/w3c/html/issues/584> ↵ Upstream a hook to HTML. ↵ We shouldn’t make the reader do this exercise. ↵ We need to extend this definition to handle things that are not source lists.
directive" that we could check against directive name. ↵ Move the remaining intersection algorithms into this section. ↵ Move all the subsumption algorithms into this section. ↵ TODO. ↵ TODO. ↵ TODO. ↵ TODO. ↵ Spell out the concerns Mario raised in the thread around https://twitter.com/0x6D6172696F/status/810066803653308416. ↵ Spell out the concerns Mario raised in the thread around https://twitter.com/0x6D6172696F/status/810066803653308416. ↵ #element-attrdef-iframe-cspReferenced in:
2.1. <iframe>'s csp attribute (2) (3) (4) (5) (6) (7) (8)
6.1. Requiring 'self' #iframe-csp-valid-attribute-valueReferenced in:
#abstract-opdef-set-the-embedding-csp-headerReferenced in:
4.2. Does response allow blanket enforcment of policy from request? 7. IANA Considerations
6.1. Requiring 'self' #abstract-opdef-set-the-required-cspReferenced in:
4.2.4. Does source expression A subsume source expression B? 4.2.5. Does source list A subsume source listB given their
respective origins and directive names? (2) (3) (4) (5)
4.2.6. Does policy A subsume policy B given their respective
origins? 4.3. Does subsuming policy subsume policy list given their respective
origins? #policy-subsumed-byReferenced in:
#policy-intersectionReferenced in:
#abstract-opdef-intersection-of-two-policiesReferenced in:
#abstract-opdef-intersection-of-two-source-listsReferenced in:
origins? (2)
4.2.1. Is an expression matching scheme-source or host-source grammar A similar to an expression matching scheme-source or host-source grammar B? (2) (3) (4) (5) (6) (7)
4.2.2. What is an intersection of two expressions matching scheme-source or host-source grammar A and B? #source-expression-wildcard-hostReferenced in:
4.2.1. Is an expression matching scheme-source or host-source grammar A similar to an expression matching scheme-source or host-source grammar B? (2) (3)
4.2.2. What is an intersection of two expressions matching scheme-source or host-source grammar A and B? #source-expression-wildcard-portReferenced in:
4.2.1. Is an expression matching scheme-source or host-source grammar A similar to an expression matching scheme-source or host-source grammar B? 4.2.2. What is an intersection of two expressions matching scheme-source or host-source grammar A and B? #source-expression-intersectionReferenced in:
4.2.2. What is an intersection of two expressions matching scheme-source or host-source grammar A and B? (2)
respective origins and directive names? (2) (3)