Connection-Allowlist vs CSP for AI-Generated UI

Add destination controls without removing CSP

For an application that executes AI-generated HTML or React, Connection-Allowlist provides an additional browser-enforced restriction on where that document can connect. Chrome 152 introduced the feature: the server sends URL patterns in an HTTP response header, and unmatched destinations are blocked.

CSP already controls some outbound traffic. Its connect-src directive governs interfaces including fetch, XMLHttpRequest, WebSocket, and sendBeacon. The difference is a policy organized around connection destinations across mechanisms, rather than separate resource types.

The allowlist specification includes navigation, DNS prefetch, and WebRTC in its scope. It does not prevent code injection itself. Retain CSP’s script execution restrictions instead of treating a network policy as a replacement for them.

Put the generated interface in its own context

Chrome’s adoption guide recommends a dedicated iframe for untrusted code, with the header applied to that document. This lets you narrow the generated interface’s destinations without imposing the same restrictions on every request the main application needs.

The frame must be cross-origin or appropriately sandboxed. A same-origin frame with access to a less restricted parent can escape the intended constraint through that context. The policy applies to a document or worker, not automatically to an entire origin.

For example, this response header permits the serving origin and the listed API pattern:

Connection-Allowlist: (response-origin "https://api.example.com/*")

response-origin represents the origin serving the response; quoted entries use URLPattern syntax. Data can still reach an allowed server, making the contents of that list consequential. If your host also accepts messages from generated code and calls APIs on its behalf, keep validating those messages: this policy does not validate postMessage payloads.

Allowing redirects also allows their later destinations

Enforcement blocks redirects and WebRTC by default. Even a request to an approved API can fail when the server returns a redirect. Sign-in or payment journeys are places to inspect that behavior.

The redirect rules make an important distinction: with redirects=allow, only the initial request is checked against the list. Once that request matches, subsequent redirects are allowed regardless of destination. This is not a setting for “redirects within my approved domains.”

webrtc=allow separately permits WebRTC. Enable either option for a specific requirement, rather than copying both into the policy to make broken features work. The browser’s outbound restriction also does not control what an approved server does with data after receiving it.

Collect reports, then turn on blocking

Start with the report-only header and a configured reporting endpoint. These addresses are examples to replace with your own API and report collector.

Reporting-Endpoints: network="https://reports.example/ingest"
Connection-Allowlist-Report-Only: (response-origin "https://api.example.com/*"); report-to=network

This configuration reports violations without blocking connections. Move the assessed policy to Connection-Allowlist for enforcement. Chrome’s guide directs developers to the Network panel for blocked requests and the Issues panel for header parsing problems.

As of October 2026, the specification remains a WICG draft, not a W3C Standard. Chrome support should not be read as uniform protection across browsers. The practical adoption path is an isolated generated document, existing CSP protections, and an additional connection policy where supported.