Extend the support to iframes

It would be great to easily extend the functionality onto iframes, that would allow greatly increasing sandboxing primitives currently present in the platform. We've heard multiple teams at Google that would love to see this feature implemented!

With the current proposal, there is no way for <iframe sandbox=... srcdoc=xxx> and <iframe sandbox=... src=data:text/html> to implement the Connection-Allowlist without encapsulating them with another, network-loaded iframe.

It should be enough to enable the support for it as part of <meta> in the <head> tag, but ideally a new attribute on the iframe would be more desirable. The issue with the new attribute on the iframe is that this feature could be then potentially used to selectively disable requests made by a cross-origin iframes, which might not be acceptable from the security PoV (csp= attribute had a similar issue which we then fixed).

@arturjanc

@arturjanc

My initial inclination is to consider <meta> a mistake, insofar as it forces us to change a page's policies and privileges after we've committed the document which has annoying implications for implementations and makes the world difficult to reason about.

Some kind of iframe attribute which we can reason about a priori could possibly be fine, but I don't think it would be safe to allow one page to apply a policy like this to another without an opt-in. We could probably use this kind of mechanism to address about:srcdoc and data: without headers, but it's not at all clear to me that we could get away with the same for https://victim.example/.

Do you have thoughts about whether covering local schemes would be enough, or do the use cases you care about include other servers' content?

Do you have thoughts about whether covering local schemes would be enough, or do the use cases you care about include other servers' content?

I'd love to see support for https://victim.example as well, because it's often quite difficult to reflect a dynamic header for static pages. What should work I think is the same model as we have for embedded CSP with the Allow-CSP-From response header. Support for Allow-Connect-Allowlist-From: * would be enough for the SafeContentFrame case where some of our users expressed the need for network isolation.

Support for Allow-Connect-Allowlist-From: * would be enough for the SafeContentFrame case where some of our users expressed the need for network isolation.

If there's an opt-in then I'm less concerned (though I'd suggest that opt-in would be best positioned in a header, as you suggest, and not as a <meta> tag). I'm not sure we landed on a great model with CSP:EE, but it is existence proof of such a think working in the wild to some extent.

That sounds good to me, from the product perspective <meta> is also not the easiest to control so a special attribute with opt-in header would work for us.

How about using document policy since that allows applying the policy and requires opt-in from the iframe via a response header (as also mentioned in the related issue's comment)?

Document policy could work, certainly. My vague recollection is that we didn't yet have alignment on required-document-policy(?), but conceptually it seems probably fine to me. I'm a little worried about jamming a potentially expansive allowlist into the document-policy header and/or policy attribute, but defining the list in one place and requiring acceptance of that list in another place is probably reasonable?

Hi there, has there been any further discussion on this? We have a scenario where we need to instantiate a sandbox in a parent/host page and restrict the sandbox so it can't leak any data. The parent page provides some data and some code to run inside the sandbox, and we need to be able to guarantee that the sandbox can't be escaped. The page loaded within the sandbox is usually in our control and can include the right meta tags, but as our scenario expands and in case the page is compromised or the input data is poisoned somehow, we need to ensure that nothing can escape the sandbox or leak data. I'm happy to provide more details, but we're really excited about this work and the iframe-level attributes are required for us to successfully use this spec.

We've talked about it a bit more, but neither the spec nor Chromium's implementation has made progress here. The sketch in my head is based on CSP:EE. The embedder would include:

  <iframe connectionAllowlist='("https://good.site/" response-origin)'
          src="https://embedded.widget/">...</iframe>

When issuing a navigation request to https://embedded.widget/, we'd include the following header:

  Sec-Required-Connection-Allowlist: ("https://good.site/" response-origin)

The response would include either an assertion of exactly that policy, or an acceptance of any policy an embedder on a specific origin requested. That is:

  Connection-Allowlist: ("https://good.site/" response-origin)

or

  Allow-Connection-Allowlist-From: https://embedder.site

If one of those headers is present, great! We load the frame. If not, equally great! We block the frame from rendering.

There are some questions here we'll need to answer, but this seems like a plausible approach.

The response would include either an assertion of exactly that policy, or an acceptance of any policy an embedder on a specific origin requested. That is:

Could Allow-Connection-Allowlist-From: * be also supported?

@mikewest

@mikewest - Your proposal above would meet our needs, thank you! What would be the next steps to get this added to the spec or implemented in Chromium?

@mikewest

A couple questions based on the proposed plan:

This seems like a perfect use-case for "Require Document Policy". Should we reuse it? Or does it warrant partial re-inventing here. I'd just like to avoid the platform growing many similarly-named mechanisms that mostly do the same thing but might vary in tiny ways.
~~I think we should probably stuff the resulting connection allowlist in the resulting document's policy container, do you agree @mikewest?~~

Edit: I see that we're already using policy container in the spec, oops! Nice!

/cc @jyasskin

On 2, yes: policy container all the way. I've been rewriting CSP:EE to carry the requirements on the Policy Container as well, and I'm hoping that once I get that cleaned up, it will pave a path for us to do something similar with Connection Allowlists.

On 1, let's talk about it. I do think we should have some generalizable way of dealing with things like this that one document wants to apply in an opt-in way to another. I'm less enthusiastic about stuffing everything into one syntactical mess, though. Required document policy seems to me like a great way to explain things like sandbox and document policies which themselves fit into a structured header as top-level items. I'm not sure how to take things like CSP or this allowlist syntax and nest it into a document policy. That seems like it would end up being a bit confusing. But, let's sketch it out! Might be a good topic for next week's WebAppSec meeting...

Required document policy seems to me like a great way to explain things like sandbox and document policies which themselves fit into a structured header as top-level items.

Can you explain this a bit more? Sorry, I'm not sure sandbox applies since it is unrelated; separately, I'm not sure what "as top-level items" means here.

That seems like it would end up being a bit confusing. But, let's sketch it out! Might be a good topic for next week's WebAppSec meeting...

What part of this would be confusing? It looks like the meeting was cancelled this past week (or did I just miss it somehow), so maybe we can hash it out here a bit in anticipation for the next one? If there are too many different syntaxes to try and stuff in the generic require document policy syntax, I can see how that'd get gross and confusing... And also if the opt-in from the embeddee is inconsistent, I can see how that piles onto the complexity. That's unfortunate though. Examples:

Require Document Policy forces the embeddee to recite the full policy it's opting into
CSP, on the other hand, just forces the embeddee to recite the origin it accepts any CSP from, which is quite different RDP
We'll have to see how CA wants to handle this. My instinct says we'd want embeddee to recite the full CA back that it's acknowledging, but CSP:EE got away with something much simpler so maybe that's a reasonable path...

Just following up - how do we move this forward? Are there open questions to resolve this? We have a scenario blocked by this issue, so we'd love to move forward with implementation if possible or help resolve any concerns if needed. Let me know!

@mikewest

@mikewest - Any guidance on how to move this forward to unblock us?

@krauders

@krauders: I think we have two viable paths proposed in this thread: following in the footsteps of CSP:EE by adding another attribute and handshaking headers, or building on top of Required Document Policy to the same end. I have a preference, I think @domfarolino has a preference, and others likely have quieter opinions as well.

If you'd like to put up some patches against either the spec or an implementation of one direction or another as a way of kicking the tires and giving folks something more concrete to react to, that could be helpful!

We'll also discuss this and other questions around Connection Allowlist at the webappsec meeting this Wednesday (see https://github.com/w3c/webappsec/blob/main/meetings/2026/2026-06-10-agenda.md).

One requirement to this is that the embedded CA needs to cascade into subframes. Additionally, there needs to be some enforcement that workers created by those frames are at least as constrained as the embedder - otherwise a constrained subframe would be easily capable of escaping its constraint by creating a worker or subframe.

In addition, we need to think about whether an iframe that receives a constraint via an attribute can further constrain itself by a more restrictive CA than what it's received?

Looking forward to the discussion in the upcoming meeting. Given the current state of RDP would it make sense to have CSP:EE be a starting point for an implementation for this use-case?

The suggestions here seem like a reasonable starting point:

We've talked about it a bit more, but neither the spec nor Chromium's implementation has made progress here. The sketch in my head is based on CSP:EE. The embedder would include:
  <iframe connectionAllowlist='("https://good.site/" response-origin)'
          src="https://embedded.widget/">...</iframe>
When issuing a navigation request to https://embedded.widget/, we'd include the following header:
  Sec-Required-Connection-Allowlist: ("https://good.site/" response-origin)
The response would include either an assertion of exactly that policy, or an acceptance of any policy an embedder on a specific origin requested. That is:
  Connection-Allowlist: ("https://good.site/" response-origin)
or
  Allow-Connection-Allowlist-From: https://embedder.site

For inheritance that seems reasonable to prevent easy escapes; sounds like leveraging CSP:EE may help achieve this or are there aspects we'd need to lock down more?

For the 'as strict as' aspect it seems reasonable to keep it simple with it having to match the exact policy but if it was desired would it make sense to do a simple match of multiple entries without trying to dive too deep into if a an URLPattern subsumes another?

Something like:

Provided policy: (response-origin "https://good.site/" "https://*.site.example")

Allowed Response: (response-origin "https://good.site/" "https://*.site.example")
Allowed Response: (response-origin "https://good.site/")
Allowed Response: (response-origin "https://*.site.example")

Rejected Response: (response-origin "https://other.site/")
Rejected Response: (response-origin "https://*sub.site.example")

@Brandr0id

FYI: @Brandr0id put up an initial stab at this in #29.

[Connection-Allowlist] Add embedded enforcement primitives

[Connection-Allowlist] Add connectionallowlist iframe attribute + IPC…

Bug 2056838 [wpt PR 61478] - [Connection-Allowlist] Add connectionall…

This landed in #29 and #35.

Bug 2056838 [wpt PR 61478] - [Connection-Allowlist] Add connectionall…

Navigation Menu

Repository navigation

Extend the support to iframes #1

5 remaining items

Something like:

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Extend the support to iframes #1

Description

Activity

terjanq commented on Sep 30, 2025

mikewest commented on Sep 30, 2025

terjanq commented on Oct 1, 2025

mikewest commented on Oct 1, 2025

terjanq commented on Oct 1, 2025

shivanigithub commented on Oct 20, 2025

mikewest commented on Oct 21, 2025

krauders commented on Mar 10, 2026

mikewest commented on Mar 11, 2026

terjanq commented on Mar 20, 2026

krauders commented on May 13, 2026

domfarolino commented on May 14, 2026

mikewest commented on May 15, 2026

domfarolino commented on May 21, 2026

5 remaining items

krauders commented on Jun 4, 2026

krauders commented on Jun 5, 2026

mikewest commented on Jun 8, 2026

noamr commented on Jun 8, 2026

Brandr0id commented on Jun 8, 2026

Something like:

mikewest commented on Jun 12, 2026

mikewest commented on Aug 11, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions