Contact emails [email protected]<mailto:[email protected]>
Explainer https://github.com/WICG/connection-allowlists (embedded enforcement) See also the proposal discussion: https://github.com/WICG/connection-allowlists/issues/1 Specification https://wicg.github.io/connection-allowlists/#issue-d96e905e (incubated in a Community Group). Embedded enforcement spec changes: https://github.com/WICG/connection-allowlists/pull/29 Design doc https://docs.google.com/document/d/1k7vcy3tPIYpD01DyuLEvEPYydOMAZRd8ASdIHX-uZi0 Summary Connection Allowlists is a feature designed to provide explicit control over external endpoints by restricting connections initiated via the Fetch API or other web platform APIs from a document or worker. This aspect of the feature extends Connection Allowlists to support embedded enforcement on iFrames and nested documents/workers. It allows a parent document to require an allowlist of the content it embeds. The embedded content either opts in (by asserting an at least as strict allowlist, by returning an Allow-Connection-Allowlist-From response header naming the embedder, or by being a local scheme document such as srcdoc or data:) or it is not loaded. Once applied, the requirement is enforced on the embedded document and inherited by its descendants and workers, so embedded content cannot escape the restriction by nesting. Blink component Blink>SecurityFeature>ConnectionAllowlist Web Feature ID Missing feature Motivation Connection Allowlists let a context declare the set of network endpoints it is permitted to connect to, as a defense in depth mitigation against data exfiltration. Today that declaration only constrains a context's own connections, via its own Connection-Allowlist response header. An embedder that assembles a page from third party or untrusted fragments (ad frames, embedded widgets, srcdoc or data: subframes generated at runtime) has no way to guarantee those fragments are held to the same connection restrictions it accepts for itself. Local scheme frames cannot set response headers at all, so under the base feature they have no way to participate. A real page is rarely a single origin's document. It is a composition of third party embeds, runtime generated subframes, and the documents and workers nested inside them. A page that has accepted a strict connection allowlist for itself currently has no way to ensure the content it embeds is held to a comparable restriction. That makes embedded content an attractive bypass: data the parent cannot exfiltrate directly could be handed to a more permissive child frame that ships it onward. The protection is only as strong as its weakest nested context. Embedded enforcement closes that gap. It lets a parent document require a connection allowlist of the content it embeds, and it guarantees the requirement can only tighten, never loosen, as it is inherited. Two properties make this safe and useful. First, the embedded content must opt in; an embedder cannot silently impose a policy on unwilling cross origin content. Content opts in by asserting its own at least as strict allowlist, by returning Allow-Connection-Allowlist-From naming the embedder's origin (or *), or by being a local scheme document that cannot set headers and so opts in implicitly. If none of these hold, the frame is not loaded rather than loaded unconstrained. Second, the requirement is propagated to descendants and checked again on every navigation, so a nested frame, a self-initiated navigation, or a cross-origin redirect cannot relax it. Representative use cases include a privacy or compliance sensitive application that embeds third party UI but must guarantee none of it can connect to arbitrary endpoints; a page that renders untrusted user content in a srcdoc or data: sandbox frame and wants that frame held to the same restrictions as the host (now possible, since local scheme frames can finally participate); and a constrained document that wants its guarantee to extend transitively to everything it embeds, including the workers those frames spawn. The design deliberately mirrors CSP Embedded Enforcement, reusing the CSP attribute, Sec-Required-CSP request header, Allow-CSP-From opt in, and policy container threading model that the platform already ships. Aligning the two mechanisms keeps embedded policy enforcement a single, well understood pattern rather than a set of one off handshakes. Embedders will leverage a new connectionAllowlist attribute to apply the restriction to embedded content: <iframe connectionAllowlist='("https://good.site/";<https://good.site/%22> response-origin)' src="https://embedded.widget/";><https://embedded.widget/%22%3e> Initial public proposal https://github.com/WICG/connection-allowlists/issues/1 Search tags connection allowlist, iFrame, embedded enforcement, CSP, security Goals for experimentation None Requires code in //chrome? False (implementation lives in services/network, third_party/blink, and content/browser). Tracking bug https://issues.chromium.org/issues/522111613 Estimated milestones No milestones specified. Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5657801797009408 Sent from Outlook<http://aka.ms/weboutlook> -- 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/CH4PR00MB2659A1A88608A39D3023421ED7E42%40CH4PR00MB2659.namprd00.prod.outlook.com.
