Intent to Experiment: Connection Allowlists - Embedded Enforcement Contact emails
[email protected]<mailto:[email protected]>, [email protected]<mailto:[email protected]> Explainer https://github.com/WICG/connection-allowlists (embedded enforcement: issues/1) Specification https://wicg.github.io/connection-allowlists/ Design doc https://docs.google.com/document/d/1k7vcy3tPIYpD01DyuLEvEPYydOMAZRd8ASdIHX-uZi0 Base feature design doc: https://docs.google.com/document/d/1B3LERUObjVDAKBNLpdIxbk8LC96rWUn1q8vtP9pPIuA Implementation design (in-tree): https://chromium.googlesource.com/chromium/src/+/main/docs/connection_allowlist_design.md Summary Connection Allowlists restrict the endpoints a document or worker may connect to. This extension lets a parent document require an allowlist of the content it embeds, via a connectionallowlist attribute on the iframe. The embedded document either satisfies the requirement - by opting in with Allow-Connection-Allowlist-From, by delivering an at least as strict Connection-Allowlist of its own, or implicitly if it is a local-scheme document such as srcdoc or data: - or it is not loaded. The requirement is inherited by descendants and workers and re-checked on every navigation, so embedded content cannot escape it by nesting or redirecting. Motivation Embedders increasingly need to run embedded content in a sandboxed environment. The sandbox attribute already constrains what such content may do: run script, submit forms, open popups, act with an origin. It says nothing about where that content may connect. A fully sandboxed frame can still reach any endpoint and send it whatever it can read, so the dimension that matters most for exfiltration is the one the platform cannot currently constrain. Connection Allowlists constrain exactly that, but only for the context that delivers the header. An embedder cannot hold what it embeds to a comparable restriction, so embedded content becomes the bypass. Local-scheme frames cannot set response headers at all, so they cannot participate even voluntarily. Embedded enforcement supplies the missing network dimension of the sandbox, guaranteed to only tighten as it is inherited, and mirrors CSP Embedded Enforcement (the csp attribute, Sec-Required-CSP, Allow-CSP-From) so embedded policy enforcement stays a single mechanism. User-facing problem A user cannot tell host content from embedded content; trust given to the site covers the whole page. A site can promise not to send user data to arbitrary endpoints, but cannot make that promise on behalf of what it embeds. The only containment tool available today, sandbox, cannot restrict connections. This means that one overly permissive widget, or one injected snippet in a srcdoc frame, breaks the promise invisibly. Embedded enforcement lets the site extend the promise to everything it embeds, however deeply content nests. Use cases * A privacy- or compliance-sensitive application embedding third-party UI that must not reach arbitrary endpoints. * A page rendering untrusted content in a srcdoc or data: frame - newly possible, since local-scheme frames cannot set response headers and so could not participate before. * A constrained document needing its guarantee to extend transitively to embedded frames and the workers they spawn. Accessibility, Privacy, and Security Considerations Accessibility: no impact. The feature affects only whether connections are permitted and whether a frame commits; it does not change rendering, focus, or assistive technology behavior. Security: a defense-in-depth feature, fail-closed - an unsatisfied requirement blocks the frame rather than loading it unenforced. An embedder cannot silently impose policy on unwilling cross-origin content (the embedded document must opt in), and the requirement can only tighten as it is inherited. Privacy: no new cross-origin information about the user is exposed. An embedded document can observe that it is subject to a requirement, since that requirement is sent to it directly as Sec-Required-Connection-Allowlist - information the embedder deliberately discloses, analogous to Sec-Required-CSP. A blocked document never loads and observes nothing. Blink component Blink>SecurityFeature>ConnectionAllowlist Search tags connection allowlist, iframe, embedded enforcement, CSP, security TAG review / status https://github.com/w3ctag/design-reviews/issues/1173 Status: Resolved, satisfied (closed 9 Jul 2026). Risks Interoperability and Compatibility Still incubating in the WICG, so shape and functionality may not be final. Enforcement can block a frame from loading, but only where an embedder explicitly sets the attribute, so existing content is unaffected. * Gecko: Positive - https://github.com/mozilla/standards-positions/issues/1322 (position: positive, closed 7 Aug 2026). * WebKit: No signal - https://github.com/WebKit/standards-positions/issues/583 (open, no formal reply as of this draft). * Web developers: Positive - https://github.com/WICG/connection-allowlists/issues/1 Ergonomics Follows the CSP embedded enforcement pattern developers already know. A framed document that already ships a compatible Connection-Allowlist needs no changes, and local-scheme documents opt in implicitly. Activation <iframe src="https://example.com/widget"; connectionallowlist="(response-origin)"></iframe> The framed document then opts in via Allow-Connection-Allowlist-From, delivers a subsuming Connection-Allowlist, or qualifies implicitly as a local-scheme document. WebView application risks None. The feature is inert unless an embedder sets the attribute, so no existing content changes behavior. Goals for experimentation * Validate the implementation in real deployments and confirm it unblocks the motivating partner. * Confirm the three satisfaction paths match how embedders and embedded parties actually coordinate, and that subsumption ("at least as strict as") behaves as expected for realistic allowlists. * Measure how often each outcome occurs via the four UseCounters — in particular whether blocking is rare and whether one satisfaction path dominates. * Evaluate inheritance ergonomics through nested documents and workers, and confirm the never-loosen rule causes no unexpected breakage. Ongoing technical constraints None Debuggability Blocked responses raise a DevTools issue (ConnectionAllowlistEmbeddedEnforcementIssue); a separate issue covers an invalid Allow-Connection-Allowlist->From header. Blocked requests appear in the Network panel, the handshake headers are inspectable there, and the connectionAllowlist IDL attribute is readable from the console. Will this feature be supported on all six Blink platforms? Yes. Is this feature fully tested by web-platform-tests? Yes Flag name on about://flags Experimental Web Platform features (about://flags#enable-experimental-web-platform-features). There is no dedicated about://flags entry for embedded enforcement; the separate "Connection allowlists" entry toggles only the base network feature, which is already enabled by default. Finch feature name ConnectionAllowlistEmbeddedEnforcement Origin trial feature name ConnectionAllowlistEmbeddedEnforcement Requires code in //chrome? False Tracking bug https://issues.chromium.org/issues/522111613 Estimated milestones Origin trial desktop first 156 Origin trial desktop last 159 Origin trial Android first 156 Origin trial Android last 159 Origin trial WebView first 156 Origin trial WebView last 159 Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5657801797009408 Feedback submission: https://github.com/WICG/connection-allowlists/issues Links to previous Intent discussions Intent to Prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/QHhBWQ0oUrA Base feature ChromeStatus entry: https://chromestatus.com/feature/5175745573945344 Base feature Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/lRMJ8iwaKbM Base feature Intent to Ship: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6a3d7aca.54d5f168.18adb4.00dd.GAE%40google.com -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/PH0PR00MB33477A8DDBB9B679579195ADB9B92%40PH0PR00MB3347.namprd00.prod.outlook.com.
