Chrome 152 lets websites put the browser behind a network allowlist

Chrome 152, rolling out from August 25, 2026, ships Connection Allowlists for desktop, Android and WebView. A server can send a `Connection-Allowlist` HTTP response header containing permitted URL patterns; before Chrome establishes a network connection on behalf of the protected document or worker, it checks the destination against that policy and blocks connections that do not match. Chromium’s implementation is intended to cover Fetch plus other web-platform networking primitives and supports documents, dedicated workers, shared workers and service workers. The feature completed an origin trial in Chrome 148–151 and now ships enabled for all users.

Web applications increasingly execute large dependency graphs that include third-party scripts, generated code and agent-authored code. A compromised or unexpected script can try to exfiltrate data through any network surface the page is allowed to use. Content Security Policy can already restrict many resource and connection types, but Connection Allowlists give builders a narrower, network-focused browser gate that is designed around explicit outbound destinations. The benefit comes with deployment risk: a strict allowlist can silently block identity, analytics, API or other legitimate endpoints if the policy is incomplete.

A protected page receives an authorized destination list from its server. Chrome evaluates attempted network destinations before establishing the connection, rather than depending on application code to police every fetch path. The Chromium proposal covers explicit requests from documents and workers and is intended to span fetches, navigations and other network-capable web APIs.

Chromium’s motivation explicitly compares Connection Allowlists with Content Security Policy. CSP covers a broader set of browser security controls and uses multiple resource-specific directives. Connection Allowlists focus on one problem: where a page is allowed to initiate network communication. Security teams should treat the two as additive tools rather than assume one subsumes the other.

Chrome’s August 27 FedCM guidance shows the operational risk clearly. Sites that opt into Connection Allowlists and use federated identity must include the Identity Provider endpoints FedCM needs, including discovery and configuration URLs, or sign-in can fail. Sites that do not use Connection Allowlists need no change. The same dependency-inventory discipline applies to APIs, CDNs, telemetry and other outbound services.

Chromium’s Intent to Ship says the feature is expected to remain Chromium-only for the foreseeable future. Mozilla and WebKit had not given implementation commitments at ship time, although standards discussions were active. A site can deploy the header as a Chromium security enhancement, but it should not treat the policy as a universal web-platform enforcement layer yet.

Because an incomplete policy can break production traffic, builders should begin with inventory and reporting before enforcing a narrow allowlist. Enumerate first-party and third-party destinations, cover worker contexts, exercise authentication and checkout flows, and make sure incident/debugging tooling can distinguish a connection blocked by browser policy from an ordinary network failure.