Chrome 152 reached stable on August 25, 2026, and buried in the "Performance and networking" section of the release notes is a feature that deserves more attention than a bullet point: Connection Allowlists.
The pitch is one sentence. You send an HTTP response header listing the endpoints your page is permitted to connect to. Chrome blocks every outbound connection that does not match — before the socket opens, at the network layer, regardless of what your JavaScript thinks it is doing.
If that sounds like Content Security Policy, it is worth understanding why the spec authors decided CSP was the wrong tool.
The problem: connect-src was never the whole story
Data exfiltration does not care about resource types. A compromised third-party analytics script can encode a session token into an image URL just as easily as into a fetch() body. CSP splits the world into img-src, font-src, connect-src, script-src and a dozen more, which means locking down exfiltration paths requires you to get all of them right, simultaneously, forever.
The spec is blunt about this: CSP's model "is too granular," because "data leaking through a request for a web font is just as bad as data leaking through a request for an image or a script."
There is also a coverage gap. CSP does a reasonable job of covering things that flow through Fetch. It does a much patchier job of covering DNS prefetch, preconnect, WebTransport, and WebRTC's STUN/TURN connections — all of which are perfectly good channels for moving bytes off a device.
Connection Allowlists collapse all of that into one question: is this destination on the list?
The header
The header is an RFC 9651 structured field — a list of inner lists, where only the first inner list is used and the rest are ignored.
Connection-Allowlist: (response-origin "https://cdn.example" \
"https://*.example.:tld" "https://api.example:*"); \
report-to=csp-endpoint
Three things to notice.
Entries are URL patterns, not CSP host-sources. That is a real upgrade. You get wildcards in the hostname, the port, and the path, with the same matching semantics as the URLPattern constructor you may already be using in a router. "https://api.example:*" means any port; "https://*.example.:tld" matches subdomains across TLDs.
response-origin is a token, not a string. It expands to the ASCII serialization of the origin the response was served from — the equivalent of 'self'. Quote it and it will be parsed as a (probably invalid) URL pattern instead.
report-to names a Reporting API endpoint, not a URL. You still need a separate Reporting-Endpoints header to define where csp-endpoint actually points.
Parsing is deliberately lenient: anything the parser does not understand is skipped rather than rejected. A typo in one pattern silently drops that pattern and keeps the rest of the policy enforcing. That is friendly to future syntax extensions and hostile to your debugging session, which is why the report-only mode below is not optional in practice.
The defaults that will break your site
Two parameters default to block, and both of them will catch teams off guard.
Redirects are blocked by default
If a request goes through any redirect, it is blocked — even if the final destination is on your allowlist. The reasoning is that once a request leaves the client, the redirect target is under the server's control, so an open redirect on an allowed origin would otherwise punch a hole straight through the policy.
Opt back in explicitly:
Connection-Allowlist: (response-origin "https://api.example"); redirects=allow
Anything that quietly relies on redirects will break: CDN region hops, short-link services, OAuth authorization flows, S3 pre-signed URL patterns, and any API that redirects http:// to https://. When a redirect is blocked, the violation report deliberately contains the original request URL rather than the redirect target, so you will not learn where it was headed.
WebRTC is blocked by default
Peer-to-peer connections cannot be meaningfully described by URL patterns, so the spec offers a single global switch rather than pretending otherwise:
Connection-Allowlist: (response-origin "https://api.example"); webrtc=allow
If your app does video calls, screen sharing, or uses a WebRTC data channel for anything, this is a hard requirement, not a nicety.
Roll it out in report-only mode first
Connection-Allowlist-Report-Only parses identically but only reports. Ship this first, on a real production route, for at least a full billing cycle of third-party behavior:
Reporting-Endpoints: net-allowlist="https://example.com/_reports/allowlist"
Connection-Allowlist-Report-Only: (response-origin "https://api.example"); \
report-to=net-allowlist
Violation reports arrive as a ConnectionAllowlistViolationReport, which carries the document url, the connection that was attempted, the allowlist that was violated, and the disposition ("enforce" or "report"). A minimal collector:
// Cloudflare Pages Function / Worker
export async function onRequestPost({ request }) {
const reports = await request.json();
for (const r of reports) {
if (r.type !== 'connection-allowlist') continue;
console.log('blocked connection', r.body.connection, 'on', r.body.url);
}
return new Response(null, { status: 204 });
}
Both headers can be sent at once — enforce a narrow, known-good policy while report-only mode tests a stricter one. Each allowlist is evaluated independently, and a violation of the report-only policy will not block anything.
For local iteration, enable chrome://flags/#connection-allowlist, then watch the Network panel for requests marked blocked:other and the Issues tab for header parsing errors.
Where this actually earns its keep
The feature was announced during the origin trial (Chrome 148–151) with generative AI front and center, and that framing holds up. If your product executes code it did not write — a formula sandbox, a plugin surface, a notebook cell, an LLM-generated snippet — you have a data exfiltration problem that no amount of application-level validation fully solves. Making the browser the gatekeeper is a categorically stronger position than making your own runtime the gatekeeper.
The second case is more common: third-party script sprawl. A checkout page typically loads a tag manager, two analytics vendors, a session recorder, and a fraud SDK. Any one of them can be compromised upstream. A Connection Allowlist means a compromised vendor script can still run, but it cannot ship your customer's card form anywhere new.
The spec also defines embedded enforcement, modeled on CSP's version: an embedder declares a required allowlist via a connectionAllowlist attribute on the <iframe>, the browser forwards it as a Sec-Required-Connection-Allowlist request header, and the framed document must opt in — either by asserting a policy at least as strict, or by returning Allow-Connection-Allowlist-From naming the embedder's origin. A frame that does not opt in is blocked entirely. That is the piece that turns this from "I trust my own code" into "I can constrain a widget I did not write," so it is worth tracking whether Chrome's implementation covers it yet.
Be clear on the limits. The spec is explicit that this "does not aim to prevent (or even substantially mitigate) threats like content injection or cross-site scripting" — it constrains the blast radius, nothing more. It only defends the pages that carry the header. It does not cover side channels. And an attacker who can set your response headers has already won. This is one layer, not a replacement for CSP, Trusted Types, or SRI.
Practical takeaways
- Chromium-only today. Chrome 152 stable on desktop and Android. Treat it as defense-in-depth on top of CSP, not a substitute — the header is inert everywhere else.
- Start report-only. The lenient parser plus the block-by-default redirect behavior make a blind enforcement rollout a genuinely bad idea.
- Audit redirects before you enforce. This is the single most likely thing to break, and the reports will not tell you the destination.
- Highest value first. Checkout, auth, admin, and any surface that runs untrusted or generated code. A marketing landing page gains almost nothing.
- Keep the policy in code review. URL patterns are terser than CSP host-sources, which makes the header short enough that a reviewer will actually read it. Do not squander that by generating it dynamically.
The web platform has spent a decade adding controls over what a page may load. This is the first one narrowly aimed at what a page may reach, and the narrowness is the point.
Sources: Chrome 152 release notes · Connection Allowlists origin trial announcement · Connection Allowlists specification (WICG)