v157 · security · early / enterprise-gated

Connection Allowlists - Embedded Enforcement

Connection Allowlists let a document restrict which endpoints it may connect to via a Connection-Allowlist response header of URL patterns. This extension gives the embedder a say: a connectionallowlist attribute on <iframe> declares the allowlist a framed document must accept. The browser forwards the requirement in a Sec-Required-Connection-Allowlist request header; the framed document opts in by asserting a satisfying Connection-Allowlist or an Allow-Connection-Allowlist-From naming the embedder — or it does not load. Modeled on CSP Embedded Enforcement.

concepts

  1. Surface probe & header echo

    Probes the exact IDL — 'connectionAllowlist' in HTMLIFrameElement.prototype — and its attribute↔property reflection, then frames a live same-origin echo page (with the attribute genuinely set) that reports whether a real Sec-Required-Connection-Allowlist arrived on its navigation request. Also proves the Sec- prefix is script-forbidden with a real fetch.

  2. Allowlist builder

    An interactive builder for the exact structured-header syntax: URL patterns, the response-origin token, report-to / redirects / webrtc parameters, the report-only variant — emitting the header line, the <iframe connectionallowlist> markup, and the Allow-Connection-Allowlist-From opt-in. With a live URL-pattern matcher (real URLPattern calls) and the spec's satisfies/subset comparator.

  3. Opt-in handshake lab

    The three-way handshake with real headers: this site's server frames a widget that opts in by satisfying allowlist, opts in by Allow-Connection-Allowlist-From, or refuses both — while the parent sets connectionallowlist for real. The widget reports its genuine request/response headers and runs real fetches to allowed-path and blocked-path endpoints. What you see is this browser's honest behaviour, labelled as the unrestricted baseline where enforcement is absent.

why it is proposed

A page can lock down its own exfiltration channels with Connection-Allowlist, but the documents it frames assert their own policies — an embedder had no way to require that a third-party widget be at least as constrained as itself. Embedded enforcement adds that control with consent: the embedder states a requirement, the framed document must explicitly opt in (satisfying allowlist, or naming the embedder), and local-scheme frames inherit the requirement through the policy container so a constrained context cannot escape via a permissive child. A frame may tighten, never loosen, its inherited requirement. The feature targets exfiltration-sensitive deployments (notably enterprise) and, per ChromeStatus, has no shipped milestone yet — it is listed against 157 while in incubation, with an origin-trial/flag path (ConnectionAllowlistEmbeddedEnforcement).

the proposed surface

<!-- embedder requires an allowlist of the framed widget -->
<iframe connectionallowlist='("https://good.example" response-origin)'
        src="https://widget.example/"></iframe>

// reflected IDL attribute
partial interface HTMLIFrameElement {
  [CEReactions] attribute DOMString connectionAllowlist;
};

// UA → framed document (forbidden request header, Sec- prefixed)
Sec-Required-Connection-Allowlist: ("https://good.example" response-origin)

// framed document opts in — either by satisfying…
Connection-Allowlist: ("https://good.example" response-origin)
// …or by naming the embedder:
Allow-Connection-Allowlist-From: https://embedder.example

references