Connection Allowlists origin trial: Secure your web application's network
Published: April 16, 2026
Because web applications become more complex, especially with the rise of integrated Generative AI, protecting user data is a top priority. That's why we are announcing the origin trial for Connection Allowlists, a new security mechanism that creates a network sandbox for documents and workers.
Background
In a modern web ecosystem, sensitive data constantly moves between clients and servers. This mobility, combined with a complex supply chain of third-party scripts and the rise of dynamically generated code from generative AI, significantly increases the risk of data exfiltration.
Malicious scripts, vulnerabilities in bundled libraries, or unintended behaviors in generative AI-generated code can bypass application-level checks to send sensitive information to unauthorized endpoints. While Content Security Policy (CSP) is a powerful tool for controlling what a page can load and execute, managing its complexity to specifically restrict where a page communicates can be challenging. This often leads to broad policies that leave room for unauthorized network activity.
Connection Allowlists provide a direct method to address these risks by making
the browser the gatekeeper of all network connections originating from your
page. By including the Connection-Allowlist HTTP response header, a site
specifies the exact URL patterns permitted for all network communication
initiated by its context, such as a document or a web worker.
This feature enforces a framework-level "deny-by-default" firewall. Before any connection is established, for example, a subresource fetch, a navigation redirect, or a WebSocket connection, the browser verifies the destination against the allowlist. If the endpoint does not match, the browser blocks the connection at the network level. The browser maintains network boundaries even if malicious code attempts to bypass application-level logic.
How Connection Allowlists work
Connection Allowlists provide a direct method to address these risks by making
the browser the gatekeeper of all network connections originating from your
page. By including the Connection-Allowlist HTTP response header, a site
specifies the exact URL patterns permitted for all network communication
initiated by its context. For the origin trial, this is supported for document
contexts only.
Before any connection is established, for example, a subresource fetch, a navigation redirect, or a WebSocket connection, the browser verifies the destination against the allowlist. If the endpoint does not match, the browser blocks the connection at the network level. This ensures that network boundaries are maintained even if malicious code attempts to bypass application-level logic.
Use the response-origin token
You can use the response-origin token, which dynamically adds the origin from
which the response is served to the allowlist:
Connection-Allowlist: ("https://api.example.com/*" response-origin)
In this example, the page can connect to any path on its origin and the specified API endpoint.
Report violations
To monitor potential issues without disrupting your site's functionality, you
can use the Connection-Allowlist-Report-Only header. This variant parses the
policy and sends violation reports to a specified endpoint using the Reporting
API.
Connection-Allowlist: ("https://trusted.com/*"); report-to=security-endpoint
Key use cases
Connection Allowlists are useful for high-security or dynamic environments:
- Generative AI and untrusted code: If your site lets users execute generated or untrusted code, for example, in Sheets Canvas or development sandboxes, Connection Allowlists can prevent the code from exfiltrating data to external domains.
- Third-party oversight: You can ensure that even if a third-party script is compromised, it cannot send data to unauthorized servers.
- Architectural safeguards: Enforce a strict network boundary for sensitive parts of your application, ensuring communication only with approved backends.
Differences from Content Security Policy
While Connection Allowlists and CSP have similar goals, they are complementary:
- Network-level focus: Connection Allowlists focus on the destination of network connections, rather than how a resource is loaded or executed.
- Comprehensive coverage: It covers navigations, redirects, and various web platform APIs, for example, Fetch, WebRTC, WebTransport, DNS prefetch, and preload, in a unified manner.
- Simplified syntax: Connection Allowlists focus on a single task, which simplifies configuration and security auditing.
Experiment with Connection Allowlists
The Connection Allowlists feature is available for local testing. The origin trial is scheduled to run from Chrome 148 to Chrome 151. Functionality continues to be added as the origin trial progresses. At the start of this trial, the reporting functionality is limited to document contexts; Dedicated, Shared, and Service Workers are not supported. More details on what is supported is in the Register for the origin trial section.
Test locally
- Enable the flag: Open Chrome and navigate to
chrome://flags/#connection-allowlist. Set the flag to Enabled. - Deploy the header: Configure your local development server to send the
Connection-AllowlistHTTP response header. For example,Connection-Allowlist: ("https://api.example.com/*" response-origin). - Verify with DevTools: Open Chrome DevTools and perform actions that trigger
network requests.
- Network panel: Check for requests that are "blocked:other" or show a connection error.
- Issues tab: Look for detailed reports if there were any parsing errors in your header.
Register for the origin trial
While local testing is great for development, you'll need to register for the origin trial to enable Connection Allowlists for your users in production.
- Navigate to the Chrome origin trials dashboard.
- Find the Connection Allowlists origin trial and click Register.
- Add the generated token to your site's pages or headers as described in the Get started with origin trials guide.
The origin trial is scheduled to run from Chrome 148 to Chrome 151. Functionality continues to be added as the origin trial progresses, so you are strongly encouraged to continue to use your existing web-security mechanisms while testing Connection Allowlists. The Intent to Experiment further details the network endpoints covered by Connection Allowlists implementation.
Provide feedback
Provide feedback on the feature's design and utility. If you encounter issues or have suggestions for improvements, contact the team:
- GitHub: Open an issue or comment on an existing one in the
WICG/connection-allowlistsrepository. - Chromium bug tracker: Create an issue in the Chromium bug tracker.