Content Security Policy: Embedded Enforcement W3C Working Draft , 7 May 2026 More details about this document This version: https://www.w3.org/TR/2026/WD-csp-embedded-enforcement-20260507/ Latest published version: https://www.w3.org/TR/csp-embedded-enforcement/ Editor's Draft: https://w3c.github.io/webappsec-cspee/ Previous Versions: https://www.w3.org/TR/2026/WD-csp-embedded-enforcement-20260422/ History: https://www.w3.org/standards/history/csp-embedded-enforcement/ Feedback: [email protected] with subject line “ [csp-embedded-enforcement] … message topic … ” ( archives ) Github Editors: Mike West ( Google Inc. ) Antonio Sartori ( Google Inc. ) Participate: File an issue ( open issues ) Tests: web-platform-tests content-security-policy/embedded-enforcement/ ( ongoing work ) Copyright © 2026 World Wide Web Consortium . W3C ® liability , trademark and permissive document license rules apply. Abstract This document defines a mechanism by which a web page can impose CSP requirements onto a frame, embedding a document if and only if it agrees to enforce a particular set of restrictions upon itself. Status of this document This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index. This document was published by the Web Application Security Working Group as a Working Draft using the Recommendation track . This document is intended to become a W3C Recommendation. The ( archived ) public mailing list [email protected] (see instructions ) is preferred for discussion of this specification. When sending e-mail, please put the text “csp-embedded-enforcement” in the subject, preferably like this: “[csp-embedded-enforcement] …summary of comment… ” Publication as a Working Draft does not imply endorsement by W3C and its Members. This is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to cite this document as other than a work in progress. This document was produced by the Web Application Security Working Group . This document was produced by a group operating under the W3C Patent Policy . W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent that the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy . This document is governed by the 18 August 2025 W3C Process Document . Table of Contents 1 Introduction 1.1 Examples 2 Framework 2.1 <iframe> ’s csp attribute 2.2 The Sec-Required-CSP HTTP Request Header 2.3 The Allow-CSP-From HTTP Response Header 2.4 Integration with HTML 2.4.1 Required CSP 3 Implicit Policy Acceptance 3.1 Intersection 3.1.1 CSP List intersection 3.1.2 Policy Intersection 3.1.3 Source List Intersection 3.1.4 Source Expression Intersection 3.1.4.1 scheme-source and host-source intersections 3.1.5 Intersection Helpers 3.1.5.1 Effective Directive Value 3.1.5.2 Effective Source List 3.1.5.3 Source Expression Similarity 3.2 Subsumption 3.2.1 CSP List Subsumption 3.2.2 Policy Subsumption 3.2.3 Source List Subsumption 3.2.4 Source expression subsumption 4 Algorithms 4.1 Is response to request blocked by requiredCSP ? 4.2 Does response allow blanket enforcement of policy from request ? 4.2.1 Rewrite 'self' into a host-source expression for origin . 5 Security Considerations 5.1 Threat Model 5.2 Policy Enforcement 5.3 Header Reflection 5.4 Header Length 6 Privacy Considerations 6.1 Policy Leakage 6.2 Data Exfiltration 7 Authoring Considerations 7.1 Requiring 'self' 8 IANA Considerations Conformance Document conventions Conformant Algorithms Index Terms defined by this specification Terms defined by reference References Normative References IDL Index Issues Index 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 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: <iframe src="https://advertisements-r-us.example.com/ad1.cfm" csp ="script-src https://trusted-cdn.example.com/"> </iframe> This will generate a request to advertisements-r-us.example.com that has a ` Sec-Required-CSP ` header, as follows: GET / HTTP/1.1 Host: advertisements-r-us.example.com ... Sec-Required-CSP : script-src https://trusted-cdn.example.com/ ... 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 ): HTTP/1.1 200 OK ... Allow-CSP-From : 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 ... Content-Security-Policy : script-src https://trusted-cdn.example.com/; object-src 'none' 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: HTTP/1.1 200 OK ... Content-Security-Policy : script-src https://trusted-cdn.example.com/, object-src 'none' 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. 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: 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 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 . 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: value is not the empty string. 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. value matches the serialized-policy ABNF grammar defined in [CSP] . One of the following statements is true: element ’s node document ’s policy container ’s required CSP is null . The result of parsing value as " enforce " is subsumed by element ’s node document ’s policy container ’s required CSP . The result of parsing value as " enforce " has a directive set that does not contain any of the following directives: report-uri report-to The following strings are valid values for the csp attribute, as they’re valid CSP grammar: script-src 'none' script-src 'self'; object-src 'none'; sandbox not-a-directive https://whatever.not-a-tld 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 attribute values: script-src *\nInjected-Header: XSS! 💩 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 . 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 , 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 Sec-Required-CSP header for a given request ( request ) and serialized CSP -or-null ( requirement ), run the following steps: If request is not a navigation request , return. 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 . 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 iframe elements have a csp attribute, defined in § 2.1 <iframe>’s csp attribute . Add a required CSP item to the policy container struct , which is a serialized CSP or null, and is initially null. Add a required CSP item to the target snapshot params struct , which is a serialized CSP or null. 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 . Add a required CSP item to the navigation params struct , which is a serialized CSP or null. 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 . Add the following step to HTML’s create navigation params by fetching algorithm, after request is created: set the Sec-Required-CSP header for request and targetSnapshotParams ’s required CSP . Update create navigation params by fetching to set the required CSP of the returned navigation params to targetSnapshotParams ’s required CSP . Update create navigation params from a srcdoc resource to set the required CSP of the returned navigation params to targetSnapshotParams ’s required CSP . 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: If requiredCSP is not null: Let required policy be the result of parsing requiredCSP as " enforce ". Let response policies be the result of parsing response ’s Content Security Policies. If § 3.2.1 CSP List Subsumption returns " Does Not Subsume " when executed upon required policy , response ’s url ’s origin , response policies , and response ’s url ’s origin : Append required policy to result ’s CSP list . Note: If the response’s policies already subsume the required policy, we do not append the required policy to the policy container. This ensures that if an embedder requires a specific nonce (e.g. nonce-abc ), and the embedee provides its own compatible nonce (e.g. nonce-xyz ), the user agent only enforces the embedee’s nonce. If we were to append both, the document would effectively block all scripts, as no script could satisfy both nonces simultaneously. Set result ’s required CSP to requiredCSP . Update create navigation params by fetching to pass targetSnapshotParams ’s required CSP to creating a policy container from a fetch response . 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 To determine the required CSP for a given navigable ( navigable ), run the following steps: If navigable is not a child navigable , return null . If navigable ’s container has an csp attribute with a valid attribute value ( value ), return value . Return navigable ’s container document ’s policy container ’s 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. Here, we’ll refer to the "at least as strict" concept as "subsumption". One content security policy object ( A ) is said to subsume another ( B ) if everything allowed by B is also allowed by A . In this case, A subsumes B , or B is subsumed by A . We’re not always comparing single policies, though. When multiple policies are present in a CSP list , 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 . Details are spelled out in § 3.1 Intersection below. With intersection defined, we can say that A subsumes a CSP list iff A subsumes that list’s 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). Let result be a content security policy object with an empty directive set , and a disposition of " enforce ". For each policy in list : If policy ’s disposition is " report ", continue . Set result to the intersection of result and policy for origin . Return result . The intersection of the policies created by parsing each item in the following list of serialized CSPs : « "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", » is the policy created by parsing the following serialized CSP : "default-src 'self' http://example.com http://example.net; connect-src 'none'; script-src http://example.com/; style-src 'self'" Each policy specified in the initial list subsumes the intersection. 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: 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 content security policy object with an empty directive set , and a disposition " enforce ". Let directive names be an empty set . For each directive in A : Append directive ’s name to directive names . For each directive in B : Append directive ’s name to directive names . For each directive name in 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 . If directive A is null : Let directive be a new directive with the following properties: name directive name value directive B ’s value append a directive to policy ’s directive set . Continue . If directive B is null : Let directive be a new directive with the following properties: name directive name value directive A ’s value append a directive to policy ’s directive set . Continue . Let directive value be the intersection of directive A ’s value , directive B ’s value , directive name , and origin . Let directive be a new directive with he following properties: name directive name value directive value Append directive to policy ’s directive set . Return policy . The intersection of the policies obtained by parsing the following serialized CSPs : "default-src 'self' http://example.com http://example.net; connect-src 'none';"
and
"connect-src http://example.com/; script-src http://example.com/" is the policy obtained by parsing the following serialized CSP : "default-src 'self' http://example.com http://example.net; connect-src 'none'; script-src http://example.com/;" 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/ ". 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' ». 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 . Let schemes be an empty set . Let intersection be an empty source list . For each expression B in effective B : 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. For each expression in schemes : If expression does not match " https: " or schemes does not contain " http: ": If expression does not match " wss: " or schemes does not contain " ws: ", append expression to intersection . For each expression A in effective A : If expression A matches scheme-source grammar and schemes contains expression A , continue . For each expression B in effective B : If at least one of expression A and expression B does not match scheme-source or host-source grammar: 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 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 the intersection of expression A and expression B is not null , append the result to intersection . Return intersection . In these cases, intersection is an intersection for A and B . A = wss: http://example.com B = https: wss: 'none' intersection = wss: https://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 . A = http://sub.a.com http://*.b.com B = https://sub.a.com:* http://*.c.com intersection = https://sub.a.com Only two sources are similar: "http://sub.a.com" in A is similar to "https://sub.a.com:*" in B so the intersection of the two source lists is "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' 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'". 3.1.4. Source Expression Intersection A 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 of A and B . A = https: B = http: Intersect = https: // http: allows both http: and https: , so https: is the intersection. A = http://*.example.com B = https://sub.example.com:* Intersect = https://sub.example.com:443 // A does not specify a port, so only default ports are allowed. A = http://example.com:80/page1/html B = https://example.com:443/ Intersect = null // A is explicitly locked to port 80, which cannot match B's equally explicit port 443. A = https: B = http://example.com Intersect = https://example.com . A = https://sub.example.com:* B = http://*.example.com/page.html Intersect = https://sub.example.com/page.html 3.1.4.1. scheme-source and host-source intersections Given two source 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 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. 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. 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. If host A is not null : 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 . 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. If port A is null , append ":" and port B to source if it is not null . If port A 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 . 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. If path A is null , append path B to source if it is not null . If path A 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 . Return source . 3.1.5. Intersection Helpers 3.1.5.1. Effective Directive Value Given a string ( name ) and a content security policy object ( 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: " child-src " " connect-src " " font-src " " img-src " " manifest-src " " media-src " " object-src " " script-src " " style-src " 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 . Return null . " script-src-elem " " script-src-attr " 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 " script-src ", return that directive ’s value . If policy ’s directive set contains a directive whose name is " default-src ", return that directive ’s value . Return null . " style-src-elem " " style-src-attr " 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 " style-src ", return that directive ’s value . If policy ’s directive set contains a directive whose name is " default-src ", return that directive ’s value . Return null . " frame-src " 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 " child-src ", return that directive ’s value . If policy ’s directive set contains a directive whose name is " default-src ", return that directive ’s value . Return null . " worker-src " 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 " child-src ", return that directive ’s value . If policy ’s directive set contains a directive whose name is " script-src ", return that directive ’s value . If policy ’s directive set contains a directive whose name is " default-src ", return that directive ’s value . Return null . " base-uri " " block-all-mixed-content " " default-src " " frame-ancestors " " form-action " " plugin-types " " report-uri " " require-sri-for " " sandbox " " upgrade-insecure-requests " If policy ’s directive set contains a directive whose name is name , return that directive ’s value . Return null . Return null . 3.1.5.2. Effective Source List 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' ». Let result be an empty source list . For each expression in list : If expression is " 'self' ": Append the result of executing § 4.2.1 Rewrite 'self' into a host-source expression for origin. given origin to result . Continue . If expression matches the keyword-source grammar, and name is not " script-src " or " style-src ", continue . Continue if any of the following statements are true: expression is " 'none' " 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' " name is " plugin-types ", and expression does not match the serialized-source-list grammar If expression is the U+002A ASTERISK character ( * ): For each scheme in « " ftp: ", " http: ", " https: ", " ws: ", " wss: " »: Append scheme to result . Append the concatenation of origin ’s scheme and " : " to result . Continue . If expression matches the scheme-source grammar: If expression is " http: ", append " https: " to result . If expression is " ws: ", append " wss: " to result . If expression matches the host-source grammar: 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 . Append expression to result . If result is empty or « 'strict-dynamic' », return « 'none' ». Return result . For any directive with origin https://example.test/ : https: wss: 'none' 'self' 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. For " style-src ": http://example.com 'strict-dynamic' 'nonce-abc' The effective source list is "http://example.com 'nonce-abc'" since "'strict-dynamic'" is ignored in non-" script-src " directives. For " script-src ": http://example.com 'strict-dynamic' 'nonce-abc' The effective source list is "'strict-dynamic' 'nonce-abc'" since "'strict-dynamic'" in " script-src " case does not honor host and scheme source expressions. 3.1.5.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-part s 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 matches the keyword-source , nonce-source , or hash-source grammar: If A is B , return " Similar ". Return " Not 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. Return " Not Similar " if any of the following is true: 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 . Return " Similar ". A = 'nonce-ch4hvvbHDpv7xCSvXCs3BrNggHdTzxUA' B = 'nonce-ch4hvvbHDpv7xCSvXCs3BrNggHdTzxUA' Since both A and B match the nonce-source grammar and A is B , A is similar to B . A = https://inner.example.com/foo/ B = http://*.example.com/foo/bar/ Since A has a wildcard host , it matches any subdomain which in this case is "inner" so that A is similar to B . A = http://*.example.com B = https://inner.example.com:* 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". A = http://example.com:80/page1/html B = https://example.com:443/ Since A and B explicitly specify different ports, A is not similar to B . A = 'sha256-abc123' B = 'sha512-cde456' Even though both A and B match the hash-source grammar, A is not a match for B because the hashes don’t match. A = http://example.com:80 B = http://example.com:334 In this case, ports of A and B do not match so that the two sources are not similar . A = http://example.com/page.html B = http://example.com/index.html The two sources are not similar because their paths do not match. Move the remaining intersection algorithms into this section. 3.2. Subsumption 3.2.1. CSP List Subsumption 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. 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 § 3.2.2 Policy Subsumption given subsuming policy , subsuming origin , effective policy , and origin . 3.2.2. Policy Subsumption 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. If A ’s directive set is empty , return " Subsumes ". For each directive A in A ’s directive set : 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 " frame-ancestors ": If effective directive B is « " 'none' " », continue . If effective directive A is « " 'none' " », return " Does Not Subsume ". For each expression B in effective directive B : Let found match be false . For each expression A in effective directive A : If § 3.2.4 Source expression subsumption 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 ". If directive A ’s name is " plugin-types ": For each type B in effective directive B : If effective directive A does not contain type B , return " Does Not Subsume ". If directive A ’s name is " sandbox ": Let flags A be the result of parsing a sandboxing directive given effective directive A . Let flags B be the result of parsing a sandboxing directive given effective directive B . For each flag in flags A : 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. If directive A ’s name is " disown-opener ", continue . Otherwise: If the result of executing § 3.2.3 Source List Subsumption is " Does Not Subsume " given effective directive A , origin A , directive name , effective directive B , origin B , and directive name , return " Does Not Subsume ". Return " Subsumes ". 3.2.3. Source List Subsumption 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 directive B is " script-src " or " style-src ": 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 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 ". Let list A and list B be empty lists. For each expression A in A : If expression A is " self ", append a host-source , returned by § 4.2.1 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 . For each expression B in B : If expression B is " self ", append a host-source , returned by § 4.2.1 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 . Continue to the next expression 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 ". For each expression B in 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 ". Let found match be false . For each expression A in list A : If § 3.2.4 Source expression subsumption 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 ". Return " Subsumes ". Let directive A and directive B be " script-src ". Consider the following examples: A = "http://example.com 'sha256-xzi4zkCjuC8'" B = "http://example.com" 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 . A = "https://example.com 'sha256-xzi4zkCjuC8'" B = "http://example.com" In this case, A does not subsume B since "https://example.com" does not subsume "http://example.com". A = "http://example.com 'sha256-xzi4zkCjuC8'" B = "http://example.com 'unsafe-inline'" 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 . 3.2.4. Source expression subsumption 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 both A and B match either host-source or scheme-source grammar: 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 ". If A or B matches the scheme-source grammar: If A matches the scheme-source grammar, return " Subsumes ". Otherwise, return " Does Not Subsume ". If B has a wildcard host : 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 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 ". 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 ". If B has a wildcard port but A doesn’t have a wildcard port , return " Does Not Subsume ". 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 ". 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 ". Return " Subsumes ". If both A and B match the hash-source grammar: If A is B , return " Subsumes ". Otherwise, return " Does Not Subsume ". If both A and B match the nonce-source grammar: 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 Return " Does Not Subsume ". Subsumption for nonces and hashes should be updated to account for more permissive sources (like 'self' or '*' combined with 'unsafe-inline') logically subsuming them. 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: Return " Allowed " if requiredCSP is null . Let required policy be the result of parsing requiredCSP as " enforce ". If the § 4.2 Does response allow blanket enforcement of policy from request? algorithm returns " Allowed " when executed upon response and request , return " Allowed ". If the § 3.2.1 CSP List Subsumption algorithm returns " Subsumes " when executed upon required policy , response ’s url ’s origin , the result of parsing response ’s Content Security Policies, and response ’s url ’s origin , return " Allowed ". 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: 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. If response ’s header list has a header named ` Allow-CSP-From ` ( header ): If header ’s value is " * ", return " Allowed ". If request ’s origin , serialized and UTF-8 encoded is header ’s value, return " Allowed ". Return " Not Allowed ". 4.2.1. 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: If origin is an opaque origin , return the empty string. Return the ASCII serialization of origin . 5. Security Considerations 5.1. Threat Model This proposal aims to give documents control over the content used in a child frame which it embeds. Since frames are generally considered to be security boundaries in themselves, limiting cross-origin access quite intentionally, we should be sure to avoid weakening that boundary. Our goals, then, are to: Allow embedders to impose a Content Security Policy requirement upon arbitrary documents it embeds. Ensure that documents loaded with a given Content Security Policy requirement can’t trivially escape it (through, for instance, local scheme documents under its control). Putting the requirement into each context’s policy container allows us to rely on the same inheritance structure as CSP itself, and also provides a clear point from which to continue imposing the requirements upon documents which the embedee itself might choose to embed. Ensure that documents loaded with a given Content Security Policy requirement have visibility into the requirements being imposed, and opt-into them either explicitly (via the ` Allow-CSP-From ` header) or implicitly (via the mechanisms outlined in § 3 Implicit Policy Acceptance ). This protects embedees from malicious policy requirements which might disable critical security infrastructure. And, of course, to do the above without introducing new vulnerabilities or risks. This proposal does not intend to supplant existing isolation mechanisms like CSP’s frame-ancestors or X-Frame-Options , nor does it provide embedees with any protection beyond what iframe elements already represent. 5.2. 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.3. Header Reflection Servers should be cautious about blindly reflecting the ` Sec-Required-CSP ` header into a ` Content-Security-Policy ` response header, as the imposed policy might restrict the resulting context in unexpected ways, or be weaker than the policy the server would otherwise apply. Instead, developers are encouraged to evaluate incoming policies before accepting them by delivering an ` Allow-CSP-From ` header for trusted origins. This ensures that policies the page wishes to apply are applied, while layering the required policy on top. Since multiple policies can only tighten the restrictions, this will ensure that the server’s policy remains a solid baseline protection. 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. MegaCorp Inc. requires a policy containing 'self' on their page at https://example.com/page.html : <iframe src="https://advertisements-r-us.example.com/ad1.cfm" csp ="script-src 'self'"> </iframe> If the returned CSP is: Content-Security-Policy: script-src 'self' Then this iframe element will be loaded. If, however, the returned CSP is: Content-Security-Policy: script-src "https://example.com/" Then this iframe element will not be loaded. 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 ) Conformance Document conventions Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification. All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119] Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example" , like this: This is an example of an informative example. Informative notes begin with the word “Note” and are set apart from the normative text with class="note" , like this: Note, this is an informative note. Conformant Algorithms Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and abort these steps") are to be interpreted with the meaning of the key word ("must", "should", "may", etc) used in introducing the algorithm. Conformance requirements phrased as algorithms or specific steps can be implemented in any manner, so long as the end result is equivalent. In particular, the algorithms defined in this specification are intended to be easy to understand and are not intended to be performant. Implementers are encouraged to optimize. Index Terms defined by this specification Allow-CSP-From , in § 2.3 contains , in § 3.2.3 csp attribute for HTMLIFrameElement , in § 2.1 element-attr for iframe , in § 2.1 determine the required CSP , in § 2.4.1 effective directive value , in § 3.1.5.1 effective source list , in § 3.1.5.2 intersection dfn for CSP list , in § 3.1.1 dfn for content security policy object , in § 3.1.2 dfn for source expression , in § 3.1.4 dfn for source list , in § 3.1.3 required CSP dfn for navigation params , in § 2.4 dfn for policy container , in § 2.4 dfn for target snapshot params , in § 2.4 Sec-Required-CSP , in § 2.2 set-required-csp , in § 2.2 set the Sec-Required-CSP header , in § 2.2 source-expression similar , in § 3.1.5.3 subsume , in § 3 subsumed by , in § 3 valid attribute value , in § 2.1 wildcard host , in § 3.1.5.3 wildcard port , in § 3.1.5.3 Terms defined by reference [CSP] defines the following terms: 'none' 'self' 'strict-dynamic' 'unsafe-inline' allows all inline behavior content security policy object Content-Security-Policy CSP list directive set directives disposition frame-ancestors hash-source host-part host-part match host-source keyword-source name nonce-source parse a response's Content Security Policies parse a serialized CSP parse a serialized CSP path-part path-part match port-part port-part matches report-to report-uri scheme-part scheme-part match scheme-source serialized CSP serialized-policy serialized-source-list source expression source lists value [CSS-VALUES-4] defines the following terms: * [DOM] defines the following terms: attribute element node document [ENCODING] defines the following terms: UTF-8 encode [FETCH] defines the following terms: append header list (for request) header list (for response) local scheme navigation request origin origin-or-null policy container request response URL wildcard [HTML] defines the following terms: CEReactions HTMLIFrameElement ASCII serialization of an origin child navigable container container document create navigation params by fetching create navigation params from a srcdoc resource creating a policy container from a fetch response CSP list iframe navigable navigate navigation params opaque origin origin parse a sandboxing directive reflect request response scheme snapshot target snapshot params target snapshot params [INFRA] defines the following terms: append (for list) append (for set) ASCII case-insensitive contain continue is is empty length list set string struct [URL] defines the following terms: origin scheme [WEBIDL] defines the following terms: DOMString References Normative References [CSP] Mike West; Antonio Sartori. Content Security Policy Level 3 . 5 May 2026. WD. URL: https://www.w3.org/TR/CSP3/ [CSS-VALUES-4] Tab Atkins Jr.; Elika Etemad. CSS Values and Units Module Level 4 . 12 March 2024. WD. URL: https://www.w3.org/TR/css-values-4/ [DOM] Anne van Kesteren. DOM Standard . Living Standard. URL: https://dom.spec.whatwg.org/ [ENCODING] Anne van Kesteren. Encoding Standard . Living Standard. URL: https://encoding.spec.whatwg.org/ [FETCH] Anne van Kesteren. Fetch Standard . Living Standard. URL: https://fetch.spec.whatwg.org/ [HTML] Anne van Kesteren; et al. HTML Standard . Living Standard. URL: https://html.spec.whatwg.org/multipage/ [INFRA] Anne van Kesteren; Domenic Denicola. Infra Standard . Living Standard. URL: https://infra.spec.whatwg.org/ [RFC2119] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels . March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119 [RFC3864] G. Klyne; M. Nottingham; J. Mogul. Registration Procedures for Message Header Fields . September 2004. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc3864 [RFC5234] D. Crocker, Ed.; P. Overell. Augmented BNF for Syntax Specifications: ABNF . January 2008. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc5234 [URL] Anne van Kesteren. URL Standard . Living Standard. URL: https://url.spec.whatwg.org/ [WEBIDL] Edgar Chen; Timothy Gu. Web IDL Standard . Living Standard. URL: https://webidl.spec.whatwg.org/ IDL Index partial interface HTMLIFrameElement { [ CEReactions ] attribute DOMString csp ; }; Issues Index Upstream this to all the HTMLs. ↵ Upstream this. ↵ 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). ↵ 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 . ↵ Move the remaining intersection algorithms into this section. ↵ Subsumption for nonces and hashes should be updated to account for more permissive sources (like 'self' or '*' combined with 'unsafe-inline') logically subsuming them. ↵ ⚠ MDN HTMLIFrameElement/csp In only one current engine. Firefox None Safari None Chrome 61+ Opera ? Edge 79+ Edge (Legacy) ? IE None Firefox for Android ? iOS Safari ? Chrome for Android ? Android WebView ? Samsung Internet ? Opera Mobile ?