Repository navigation
Clarify policy enforcement for resource hints in same-origin nested contexts #12
Description
The draft notes that a document’s asserted policy governs requests initiated by that context and that policy containers apply to nested contexts in certain cases. It is unclear how this applies when resource hints (e.g., prefetch, prerender) are added dynamically to a same-origin nested browsing context, such as an iframe whose document shares the origin of the embedding page. We believe that the nested document’s Connection-Allowlist policy should govern any connections initiated by those hints and should occur before speculative networking (such as DNS pre-resolution) occurs. Clarification on the expected behavior for resource hints within nested browsing contexts would help determine the intended scope of the policy.
Activity
mikewest commentedon Mar 18, 2026
I'd distinguish between "same-origin nested browsing contexts" as there's one clear distinction:
Navigations to local scheme documents (e.g.
<iframe srcdoc="...">,<iframe src="blob:...">, etc) will clone the initiator's policy container, thereby applying the same restrictions in the nested context that apply to the initiator.Navigation to non-local schemes will create a policy container from the HTTP response, meaning that it's possible for the embedder to have a policy distinct from the embedded document.
Within a given context, that context's policy is the one applied to outgoing connections. So, if A embeds B, B's policy will govern prefetch/prerender requests initiated from B's context.
Does that answer your question?
krauders commentedon Mar 19, 2026
That does clarify things. Is there no way for the top embedder A to restrict subframes to only allow a subset of its rules/domains? If not, then for our scenario I understand we'd have to ensure that we only allow network access to domains that we can guarantee will always return a safe set of rules in their connection-allowlists headers, is that right? This creates more exposure for us, as opposed to the embedder specifying the widest possible set of domains and policies.
mikewest commentedon Mar 20, 2026
For a scenario in which you'd like to tighten the constraints on a given frame, the discussion in #1 (where the suggestion is to rely on something similar to the
<iframe csp>attribute) is probably what you're looking for.I'm not sure I understand your comments about the breadth of the constraints expressed by the embedder, though. Can you sketch out the scenario in a little more detail?
krauders commentedon Mar 20, 2026
Sure, I think that makes sense if I'm understanding correctly. Essentially, we need the top level page/host/embedder to be able to guarantee the safety of any iframes/sandboxes it creates, including data exfiltration prevention. It's a promise made to the customer/user of that top level page. As I understand it, without the
<iframe csp sandbox>style attributes, we'd rely on the origin of the embedded page to return the correct policy. In our case, we can guarantee that for the initial embedded iframe since we control that. But then, if our policy allows requests to, say, bing.com, we can't guarantee that all pages on bing.com will return a policy that we consider secure. So if the embedded page, where we run untrusted code, creates a nested iframe to some bing.com page that does not return a secure connection-allowlists policy, then the untrusted code could execute code in the sandbox which can access other domains, effectively escaping our sandbox. Does that make sense, and am I understanding that right? So ideally, I think we'd need a way to set<iframe csp sandbox>style attributes with a policy and ensure that, if an origin returns a more permissive policy or none at all, the content would not get loaded, or perhaps our policy would be applied instead or something like that.krauders commentedon Mar 26, 2026
Hello! Just checking in on this - did my explanation and understanding make sense? Do you know if there has been progress with aligning on this approach (comparing the host page's policy and the embedded origin's policy)?
rohandubal commentedon Apr 1, 2026
@mikewest small nudge to above comment from Krists when you have a moment..
mikewest commentedon Apr 1, 2026
Sure. The requirements are clear, this just isn't at the top of my list at the moment. I've started sketching out an approach in the
iframe-attributebranch of the repo (https://github.com/WICG/connection-allowlists/tree/iframe-attribute if you'd like to send PRs).Closing this in favor of #1, as I think that's where we should be having the conversation around the story for frames.