Connection-Allowlist header, deny-by-default egress

Connection-Allowlist declares a deny-by-default allowlist of destinations a page may connect to, so the browser blocks every other outgoing connection.

Connection-Allowlist lets a document or worker declare the exact set of destinations it is allowed to connect to. The browser then becomes a deny-by-default gatekeeper: before any connection is made, it checks the destination against the allowlist and blocks anything that does not match. It is a network egress sandbox, aimed at stopping data exfiltration through any channel, a compromised script, a vulnerable bundled library, or code you did not review.

Experimental, origin trial

Connection Allowlists is a WICG Draft Community Group Report (last updated June 2026), available through an in-progress Chrome origin trial only. Nothing has shipped by default, and no other engine has signaled support. The syntax and report shape can still change.

During the origin trial, run the Report-Only header first, with the endpoint name declared in Reporting-Endpoints:

Connection-Allowlist-Report-Only: (response-origin "https://*.example.com"); report-to=connection-endpoint

How it works

You send a Connection-Allowlist response header whose value is a list of URL patterns. A connection is allowed only if its destination matches one of them. Everything else, fetch, WebSocket, WebRTC, navigation, redirects, fonts, images, is blocked at the network level.

Reporting-Endpoints: connection-endpoint="https://<Endpoint-ID>.report.centralcsp.com"

Connection-Allowlist: (response-origin "https://*.example.com" "https://cdn.example"); report-to=connection-endpoint

The value is a structured-field inner list (RFC 9651). Each entry is either the response-origin token or a quoted URL Pattern string for an absolute URL, so wildcards and subdomains use the URL Pattern grammar (https://*.example.com, https://api.example:*) rather than the CSP host-source grammar.

Values

Value	Status	Meaning
`response-origin`	🧪 Experimental	Token that adds the origin serving the response to the allowlist automatically.
`"https://..."`	🧪 Experimental	A quoted URL Pattern for an allowed destination.
`report-to=<name>`	🧪 Experimental	Names a `Reporting-Endpoints` endpoint to receive violation reports.
`redirects=block` / `redirects=allow`	🧪 Experimental	Whether to follow redirects. Default is `block`.
`webrtc=block` / `webrtc=allow`	🧪 Experimental	Whether to allow WebRTC connections. Default is `block`.

Every value is experimental: the whole header exists only behind the Chrome origin trial.

Redirects and WebRTC are blocked by default, a deliberately conservative posture to stop exfiltration through an open redirect or a peer connection. Opt back in only when you need them.

Enforce and report-only

There are two headers, the same split CSP and the other policies use. Run the report-only header first to see what a policy would block on real traffic, then enforce; the opening example shows that form.

Connection-Allowlist enforces and blocks; Connection-Allowlist-Report-Only blocks nothing and only sends a connection-allowlist report for each connection it would have blocked.

How it relates to CSP connect-src

This does not replace your Content Security Policy. The CSP connect-src directive is stable and widely supported, and it is the egress control to ship today. Connection Allowlists is the experimental egress layer arriving next, with three differences: it is uniform across every request type instead of split into per-type directives (connect-src, img-src, font-src), it uses URL Pattern syntax, and it covers connection types CSP cannot, including WebRTC (the CSP webrtc directive is spec-only, with no browser support), redirects, and navigations. Use connect-src now; consider Connection Allowlists when you want a single deny-by-default egress policy.

What it protects against

Data exfiltration, regardless of the channel. The threat model treats a leak through a font or image request as just as serious as one through fetch. By denying every destination you did not list, a skimmer or a compromised dependency has nowhere to send stolen data, even if it runs.

Insecure configurations to avoid

A broad pattern such as https://* allows any HTTPS destination and defeats the allowlist, the same mistake as connect-src * in CSP. List specific origins, and turn redirects=allow or webrtc=allow on only when a feature genuinely needs them.

Known bypasses and limitations

Experimental and Chromium-only, so it protects users only on browsers that implement it and have the origin trial enabled. It governs the destination of connections, not what a script does in the page, so it complements rather than replaces CSP and input handling.

Risks

A too-strict allowlist breaks legitimate third-party connections, which is why the report-only header exists. Roll out in report-only, watch what it would block on real traffic, and tighten before you enforce.

Recommendation

Connection-Allowlist-Report-Only: (response-origin "https://cdn.example"); report-to=connection-endpoint

If you want to evaluate it, join the Chrome origin trial and run the Report-Only header first, so you see every connection the policy would block before anything breaks. Keep the CSP connect-src directive as your enforced egress control in the meantime; it is the stable, cross-browser mechanism until Connection Allowlists ships by default somewhere.

Reporting

A report-to=<name> parameter points at an endpoint declared in a Reporting-Endpoints header, and the browser emits the connection-allowlist report for each blocked or would-be-blocked connection. CentralCSP ingests that report alongside your CSP and other browser reports, so you can run Connection-Allowlist-Report-Only and watch the blocked connections across real traffic before enforcing.

Browser support

An in-progress Chrome origin trial only; nothing has shipped by default, and no other engine has signaled support. The spec is a WICG Draft Community Group Report (last updated June 2026), not on the W3C standards track yet.

Connection-Allowlist