← All posts

Connection Allowlists, a network egress sandbox in the browser

CentralCSP Team ·

Last update:

Most client-side defenses try to stop bad code from running. Connection Allowlists take the opposite angle: assume the code runs, and make sure it has nowhere to send your data. A new browser header lets a page declare the exact set of destinations it is allowed to connect to, and the browser blocks every other outgoing connection, through any channel. A leak through a font request is treated as seriously as one through fetch.

Experimental, origin trial

Connection Allowlists is an early WICG proposal. Chrome has run it as an origin trial and intends to ship it, while Firefox and Safari have not signalled support. Treat it as something to pilot in report-only, not to depend on in production.

The problem it solves

A Content Security Policy stops most injected scripts from executing. But a script that does run, a compromised dependency, a rogue tag, AI-generated code you did not review, can still phone home: post stolen form data to an attacker origin, open a WebSocket, or smuggle bytes out in an image URL. Controlling that egress with CSP means juggling connect-src, img-src, font-src, and more, each a separate directive, and even then CSP cannot cover WebRTC or redirects cleanly.

Connection Allowlists reframe the problem around the destination, not the request type. You list where the page may connect, and the browser denies everything else at the network level.

How it works

You send a Connection-Allowlist response header listing the destinations the page may reach. Anything not on the list is blocked, including fetch, WebSocket, WebRTC, navigation, redirects, and subresource loads.

Reporting-Endpoints: connection-endpoint="https://<Endpoint-ID>.report.centralcsp.com"
Connection-Allowlist: (response-origin "https://*.example.com" "https://cdn.example"); report-to=connection-endpoint

Each entry is a URL Pattern, so subdomains and wildcards use that grammar. The response-origin token adds the serving origin automatically. Two things are blocked by default and you opt back in only if you need them: redirects (redirects=allow) and WebRTC (webrtc=allow), both common exfiltration paths.

The full header syntax, values, and the report payload are in the Connection-Allowlist reference.

Roll it out in report-only first

Just like CSP, there are two headers, and you start with the report-only one so a too-strict list reports instead of breaking the page.

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

The browser blocks nothing and sends a connection-allowlist report for every connection it would have blocked. Collect those from real traffic, confirm each blocked destination is either one to add or one you are glad to deny, then move the policy to the enforcing Connection-Allowlist header.

How it compares to CSP connect-src

This is not a CSP replacement. The connect-src directive is stable, widely supported, and the egress control to use today. Connection Allowlists are the experimental next layer: one deny-by-default policy that spans every request type, uses URL Pattern syntax, and covers WebRTC and redirects that connect-src does not. Ship a strong CSP now, and pilot Connection Allowlists in report-only to see where the egress layer would help.

Where CentralCSP fits

CentralCSP is built on the browser Reporting API and ingests every report type the browser sends. A connection-allowlist report lands in the same pipeline as your CSP, NEL, and COOP/COEP reports. Point Connection-Allowlist-Report-Only at your CentralCSP endpoint and you can watch blocked and would-be-blocked connections across real traffic, grouped by destination, the same report-only-first workflow you already run for CSP. For the supply-chain side of the same problem, see what Magecart and formjacking are and the script inventory that tracks what runs on your pages. Start free to collect the reports.

Reported outbound connections grouped by connection type and origin, each with its enforced or report-only disposition

Next steps

Sources