How to Use Chrome 152 Connection Allowlists

Chrome 152, released on August 25, adds Connection Allowlists, a browser-enforced way to restrict where a web page or worker can make network connections. Instead of relying only on application code to decide which endpoints are trusted, you can send a Connection-Allowlist response header and let Chrome check destinations before connections are established. The feature is designed for cases where a compromised dependency, injected script, or generated code could otherwise send data somewhere your application never intended. This guide shows how the policy works, how to add it to a web server, how to test it, and where it should not replace existing security controls. 

What Connection Allowlists actually protect

A Connection Allowlist defines the external endpoints that a document or worker is allowed to contact. Chrome receives that policy from the server response and checks connection destinations against it before allowing the request to proceed. The mechanism covers connections initiated through Fetch and other web platform APIs rather than restricting only one resource type. Chromium's implementation associates the policy with the context that received it and applies the restriction when requests originate from that context. 

This matters most when your application contains code you do not completely control. A third-party dependency might be compromised, a vulnerability might allow unwanted script execution, or an AI-generated component might contain an unexpected network call. Application-level checks can miss those cases because malicious code can attempt to communicate directly with an endpoint instead of going through your normal API layer. A browser-enforced network boundary gives the page another security layer that operates below that application logic. 

Start with the endpoints your application really needs

Before writing the header, make a list of the destinations your page genuinely needs to contact. Include your own application backend, approved API services, payment or authentication providers, analytics endpoints, and other services that the application actually uses. Do not begin by allowing every destination and then try to tighten the policy later, because the useful property of this mechanism is its deny-by-default approach. A smaller list also makes the resulting security policy easier to review when your application changes. 

For example, imagine a dashboard that communicates with its own backend and one approved data service. Represent those destinations with environment variables rather than placing real endpoint addresses directly in a tutorial or source template. Your deployment configuration can then provide the exact URL patterns for each environment. This approach also prevents a development endpoint from accidentally becoming part of a production security policy.

Add the Connection-Allowlist response header

The policy is delivered as an HTTP response header named Connection-Allowlist. Its value is a structured list containing URL patterns or the special response-origin token, which represents the origin that served the response. A typical server can construct this value from an environment variable containing the approved endpoint patterns. Chrome then evaluates connection destinations against the policy before establishing the connection. 

const allowedApi = process.env.ALLOWED_API_PATTERN;
const allowedCdn = process.env.ALLOWED_CDN_PATTERN;

res.setHeader(
"Connection-Allowlist",
`(response-origin "${allowedApi}" "${allowedCdn}")`
);

res.send(html);

The exact URL patterns belong in your deployment configuration, not in the application example itself. The response-origin token is useful when the page should be allowed to communicate with the same origin that delivered it. Additional entries can describe approved external destinations using the URLPattern syntax supported by the feature. Keep those patterns as narrow as your application permits rather than granting a broad wildcard without a specific reason. ([GitHub][1])

Test the policy with a real request

Once the response header is being sent, test both an allowed request and a request that should be rejected. Start with a normal application operation that you know requires an approved backend, because this confirms that your policy does not break legitimate traffic. Then trigger a request to an endpoint that is deliberately absent from the allowlist. The expected result is that Chrome blocks the connection rather than allowing the request to reach the destination. ([Chrome for Developers][2])

fetch(API_ENDPOINT, {
method: "GET"
})
.then(response => response.json())
.then(data => console.log(data))
.catch(error => console.error(error));

Use Chrome DevTools while testing so you can see which network operation fails and whether the failure comes from your policy. The Connection Allowlist design works at the network boundary, so a blocked destination can fail before your application receives a normal HTTP response. If a legitimate request is blocked, add the required endpoint only after confirming that the destination is genuinely part of the application's intended architecture. ([Chrome for Developers][3])

Use report-only mode before enforcing it

A useful deployment strategy is to discover unexpected traffic before turning on blocking. The proposal defines Connection-Allowlist-Report-Only, which lets you observe violations without immediately disrupting application behavior. Reporting uses the browser's Reporting API infrastructure and can identify destinations that your initial policy failed to account for. This is particularly valuable for large applications with dependencies that are difficult to inventory manually. ([GitHub][1])

res.setHeader(
"Connection-Allowlist-Report-Only",
`(response-origin "${allowedApi}")`
);

Run the report-only policy through normal application workflows rather than testing only the home page. Sign-in, uploads, search, checkout, background synchronization, embedded components, and less frequently used settings pages can all introduce network destinations. Compare the observed traffic with the endpoints you actually trust, then remove accidental or unnecessary dependencies before switching to enforcement. This gives you a much better chance of deploying a useful allowlist without discovering a broken feature after release.

Keep Content Security Policy in place

Connection Allowlists are not a replacement for Content Security Policy, or CSP. CSP controls how browsers load and execute different classes of resources, while Connection Allowlists concentrate on where the context can establish network connections. The two mechanisms can therefore provide overlapping but different protections. Chromium's design applies applicable restrictions additively, meaning a request must satisfy all relevant policies before it can proceed. ([Chromium Git Repositories][4])

That distinction is important when hardening an existing application. Continue using CSP to control scripts, frames, styles, and other resource-loading behavior where appropriate, while using a Connection Allowlist to establish a clear boundary around outbound communication. A strong policy also does not remove the need to patch dependencies, validate user input, protect authentication, and prevent cross-site scripting. The allowlist is an additional boundary around network communication, not a complete application-security system. ([GitHub][1])

Be careful with redirects and dynamic services

Dynamic applications make allowlisting harder because the complete set of destinations may not be obvious from the source code. Authentication and payment flows can move through several endpoints, while integrations may change their infrastructure without changing your application code. The Connection Allowlists proposal has specifically discussed redirects as an area where real-world deployments need careful treatment. You should therefore test complete workflows rather than assuming that allowing the first destination automatically makes every later hop valid. ([GitHub][1])

The same caution applies to services that generate destinations dynamically. If an application accepts a destination from a database or user-controlled input, do not solve the problem by adding a broad wildcard to the browser policy. First determine why the destination is dynamic and whether the application can constrain it to a known set of trusted origins. A narrow browser policy is most useful when it reflects an architecture that already knows where communication is supposed to happen.

Use it where the security boundary matters most

Connection Allowlists are particularly interesting for applications that execute third-party or generated code, handle sensitive information, or combine many external dependencies. Chrome's documentation specifically highlights generative AI and untrusted code as use cases because unexpected code can otherwise attempt to send information to an unauthorized server. The browser-level restriction means that even if application-level logic is bypassed, the page still has a defined set of permitted network destinations. ([Chrome for Developers][3])

Chrome 152 now lists Connection Allowlists among its stable release features, so developers can begin evaluating the mechanism against real applications rather than treating it only as an early proposal. At the same time, the underlying specification and implementation are still areas where developers should verify current browser behavior and supported use cases before depending on the feature everywhere. Start with a report-only deployment, measure what your application actually communicates with, then move to enforcement for contexts where the additional boundary provides clear value. ([Chrome for Developers][5])

How to tell whether your policy is working

A successful deployment should leave ordinary application workflows unchanged while preventing unexpected outbound destinations. Test every important feature with the policy enabled, including authentication, API calls, navigation, uploads, embedded content, and background operations used by the application. Then deliberately exercise code paths that attempt to contact an unapproved endpoint and confirm that the browser stops the connection. Finally, keep the policy close to your architecture documentation so that adding a new external service requires an explicit security review instead of silently expanding network access.