Connection Allowlists: A Firewall Inside the Browser

Chrome 152 reached stable on August 25, 2026, carrying a feature that rearranges the front-end security stack: Connection Allowlists. The idea is blunt — one HTTP response header declares the destinations a page is allowed to talk to, and the browser refuses everything else before a connection is ever opened.

The problem: we control what loads, not where it sends

Content Security Policy answered half the question: where scripts, images and styles may be loaded from. It was never designed for the second half, which is the sharper one today — once a script is running inside the page, where is it allowed to send?

That gap is exactly what supply-chain attacks live in. A single poisoned dependency inside the bundle needs no XSS hole and no DOM tampering; a fetch() to an attacker-owned domain quietly carries out tokens and form fields. The pattern repeated more than once through 2026 — see import-time npm malware. Controlling the source is not enough when the destination is where the damage happens.

What changed

Connection Allowlists move the decision down to the network layer inside the browser. The header ships with the page response and applies to every outbound connection from it:

http

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

The syntax is built on Structured Fields (RFC 8941), and URL matching reuses URLPattern rather than inventing a new grammar — so what you already know about path matching applies directly. The response-origin token automatically permits the origin that served the response, so it never has to be spelled out by hand.

The scope is wider than the name suggests. Enforcement covers subresource fetches, navigations and redirects, preload, preconnect and DNS prefetch, plus WebSocket, WebRTC and WebTransport — in documents and in dedicated, shared and service workers. A rejected request shows up in DevTools as blocked:other.

Before enforcing anything, there is report-only mode — the only realistic path for an application already in production:

http

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

It collects violations through the Reporting API without breaking anything. Watch for a week, read what genuinely leaves the page — the list is usually longer than expected — then tighten.

Real-world caveats

Chrome only, for now. The feature moved from an origin trial in versions 148–151 to shipping in 152 on desktop, Android and WebView. Mozilla and WebKit have not signalled support, and the W3C TAG review is still pending. Treat it as defence in depth, not a replacement for server-side controls.
It is not an XSS fix. The scope is the destination of a connection, not how a resource is loaded or executed. Injection stays injection; what changes is that the exit path is now narrow.
Policies intersect, they do not union. When more than one policy applies, a connection passes only if it clears all of them — the same cumulative model as CSP.
Server-side redirects are still an open discussion in the specification, and so are open redirects.
The allowlist is a living document. A new analytics tool or payment provider means updating the header, or the feature breaks silently. Tie it to the deployment process, not to somebody's memory.

Takeaway

The model teams used to build with a proxy and infrastructure-level egress rules is now available inside the browser in one line. The real value is not only the blocking — it is that, for the first time, there is an explicit written list of what the application actually connects to. Start with Report-Only, and make that list part of code review rather than of the incident runbook.

Primary source: Connection Allowlists on Chrome for Developers and the WICG specification.