# Chrome 152 lets websites put the browser behind a network allowlist Chrome 152’s new `Connection-Allowlist` response header lets a site declare the network destinations its documents and workers may contact, with Chrome blocking disallowed connections before they are established — a browser-level exfiltration control that complements CSP. Connection Allowlists turn outbound browser networking into an explicit allowlist for Fetch and other web-platform APIs. The control is opt-in and currently Chromium-only, and strict policies can break legitimate dependencies such as FedCM identity-provider requests if teams omit required endpoints. - Status: Active - Published: 2026-08-28T22:08:14+12:00 - Updated: 2026-08-28T22:08:14+12:00 - Categories: Web Development, Browsers & Web Standards - Tags: Chrome, Connection Allowlists, network security, web standards - Canonical HTML: https://beyondthe.news/dossiers/chrome-152-connection-allowlists-network-exfiltration-control ## What changed 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. ## Why it matters 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. ## The browser becomes the outbound-network gatekeeper 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. ## This complements rather than replaces CSP 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. ## Strict policies can break legitimate platform APIs 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. ## Cross-browser support is not established 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. ## Reporting and staged rollout matter 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. ## Key details - Connection Allowlists ship in Chrome 152, released beginning August 25, 2026. - The feature uses the `Connection-Allowlist` HTTP response header. - Chrome checks requested destinations against the allowlist before establishing network connections. - The feature applies to documents and dedicated, shared and service workers. - Chromium’s scope includes Fetch and other web-platform networking APIs rather than only script or asset loading. - The origin trial ran from Chrome 148 through 151. - Chrome ships the feature enabled for all users on desktop, Android and WebView. - Chromium says other browser vendors had not committed to implementation at ship time. - FedCM users who enable an allowlist must include required Identity Provider endpoints or authentication can fail. ## Builder takeaways - Inventory outbound destinations from real production sessions before enforcing a Connection Allowlist; include API, auth, CDN, analytics, WebSocket/WebTransport and worker traffic relevant to your application. - Roll out with reporting and a broad policy first, then tighten it. A typo or omitted dependency can become a production outage rather than merely a security warning. - Keep CSP and Connection Allowlists as separate controls: use CSP for its broader content/security policy and the allowlist for explicit outbound network destinations. - Test sign-in and third-party platform flows explicitly. Chrome has already documented FedCM breakage when Identity Provider endpoints are omitted. - Do not make server-side security decisions assuming every browser enforces the header; cross-browser adoption is not established. - When AI-generated or third-party code runs in the page, treat the allowlist as an additional containment layer, not permission for that code to receive secrets it does not need. ## What to watch - Whether Firefox or Safari adopt Connection Allowlists or converge on a compatible alternative. - How the specification and supported network primitives change after real-world Chrome 152 deployment. - Independent evidence on deployment breakage, bypasses and operational overhead. - Whether frameworks, CDNs and security platforms add tooling to generate or audit `Connection-Allowlist` policies automatically. - How Connection Allowlists interact with emerging agent/browser APIs and increasingly dynamic third-party application dependencies. ## Uncertainties - The feature is new in stable Chrome, so broad independent evidence on false blocks, bypasses and long-term operational patterns is limited. - Chromium intends broad networking coverage, but implementation details and edge cases can evolve with the specification. - Because cross-browser support is not established, the header is currently an additional Chromium control rather than a universal replacement for existing web security mechanisms. ## Sources - [New in Chrome 152](https://developer.chrome.com/blog/new-in-chrome-152) — Chrome for Developers · primary/vendor · 2026-08-25T00:00:00+12:00. Primary stable-release announcement confirming Connection Allowlists in Chrome 152 and the `Connection-Allowlist` header model. - [Chrome 152 release notes](https://developer.chrome.com/release-notes/152) — Chrome for Developers · primary/vendor · 2026-08-25T00:00:00+12:00. Primary release documentation confirming enforcement for connections initiated by documents and workers. - [Intent to Ship: Connection Allowlists](https://groups.google.com/a/chromium.org/g/blink-dev/c/rFiZF7fPIv4) — Chromium blink-dev · primary/standards · 2026-06-25T00:00:00+12:00. Primary implementation rationale, scope, rollout, testing and cross-browser signals. - [FedCM: Allow network requests to your Identity Provider with Connection Allowlist](https://developer.chrome.com/blog/fedcm-connection-allowlist) — Chrome for Developers · primary/vendor · 2026-08-27T00:00:00+12:00. Concrete compatibility guidance showing that incomplete allowlists can block legitimate identity-provider requests.