Connection-Allowlist

Connection-Allowlist lets a document or worker declare the exact set of destinations it is allowed to connect to. The browser then becomes a deny-by-default gatekeeper: before any connection is made, it checks the destination against the allowlist and blocks anything that does not match. It is a network egress sandbox, aimed at stopping data exfiltration through any channel, a compromised script, a vulnerable bundled library, or code you did not review.

Run the Report-Only header first, with the endpoint name declared in Reporting-Endpoints:

Connection-Allowlist-Report-Only: (response-origin "https://*.example.com"); report-to=connection-endpoint

How it worksCopy Anchor Link

You send a Connection-Allowlist response header whose value is a list of URL patterns. A connection is allowed only if its destination matches one of them. The browser blocks everything else: fetches, subresources such as fonts and images, navigations, iframes, popups, WebSockets, WebTransport, WebRTC, and redirects.

Reporting-Endpoints: connection-endpoint="https://<Endpoint-ID>.report.centralcsp.com"

Connection-Allowlist: (response-origin "https://*.example.com" "https://cdn.example"); report-to=connection-endpoint

The value is a structured-field inner list (RFC 9651). Each entry is either the response-origin token or a quoted URL Pattern string for an absolute URL, so wildcards and subdomains use the URL Pattern grammar (https://*.example.com, https://api.example:*) rather than the CSP host-source grammar.

A pattern matches the whole URL, path and query included. An entry with no path, such as "https://cdn.example", allows every path on that origin. An entry with a path, such as "https://cdn.example/assets/*", allows only the URLs under it. A *. wildcard matches subdomains only: https://*.example.com does not match https://example.com.

URLs with a local scheme, such as data: and blob:, never reach the network, so the allowlist does not apply to them.

WebSocket destinationsCopy Anchor Link

Write WebSocket destinations with https: or http:, never wss: or ws:. Before it checks a WebSocket, the browser converts wss: to https: and ws: to http:. A "wss://chat.example.net" entry therefore never matches, and the connection is blocked. Write the entry this way instead:

Connection-Allowlist: (response-origin "https://chat.example.net"); report-to=connection-endpoint

The https://chat.example.net entry in this example allows both https://chat.example.net and wss://chat.example.net.

ValuesCopy Anchor Link

Redirects and WebRTC are blocked by default, to stop exfiltration through an open redirect or a peer connection. Opt back in only when you need them.

RedirectsCopy Anchor Link

redirects=block blocks every redirected request, whatever its target. A redirect to an allowed destination is blocked, and so is a redirect that stays on your own origin, such as /account to /account/. The browser reports the URL the page requested, not the redirect target.

redirects=allow checks only the first request. The browser then follows every redirect, wherever it leads. An open redirect on an allowed destination can then send data anywhere. Turn it on only when your pages need a redirect, such as a sign-in or payment step.

Where it appliesCopy Anchor Link

The header applies to the document or worker whose response carries it:

• Documents: The page's own connections, and the requests that load its iframes and popups.
• Workers: A dedicated, shared, or service worker follows the header on its own script response, not the page's. Send the header on worker scripts too. A worker created from a blob: or data: URL inherits the policy of the context that created it.
• Cross-origin iframes: The parent's list decides whether the iframe loads. After that, the framed document follows its own headers.

Enforce and report-onlyCopy Anchor Link

There are two headers, the same split CSP and the other policies use. Run the report-only header first to see what a policy would block on real traffic, then enforce; the opening example shows that form.

Connection-Allowlist enforces and blocks; Connection-Allowlist-Report-Only blocks nothing and only sends a connection-allowlist report for each connection it would have blocked.

How it relates to CSP connect-srcCopy Anchor Link

This does not replace your Content Security Policy. The CSP connect-src directive is stable and widely supported, and it is the egress control to ship in every browser. Connection Allowlists adds a Chromium-only egress layer, with three differences: it is uniform across every request type instead of split into per-type directives (connect-src, img-src, font-src), it uses URL Pattern syntax, and it covers connection types CSP cannot, including WebRTC (the CSP webrtc directive is spec-only, with no browser support), redirects, and navigations. Keep connect-src for every browser, and add Connection Allowlists when you want a single deny-by-default egress policy in Chromium-based browsers.

What it protects againstCopy Anchor Link

Data exfiltration, regardless of the channel. The threat model treats a leak through a font or image request as just as serious as one through fetch. By denying every destination you did not list, a skimmer or a compromised dependency has nowhere to send stolen data, even if it runs.

Insecure configurations to avoidCopy Anchor Link

Known bypasses and limitationsCopy Anchor Link

It protects users only in Chromium-based browsers from version 152. It governs the destination of connections, not what a script does in the page, so it complements CSP and input handling rather than replacing them.

A worker script served without the header is not bound by the page's list. A cross-origin iframe the list allows can connect wherever its own headers permit.

RisksCopy Anchor Link

A too-strict allowlist breaks legitimate third-party connections, which is why the report-only header exists. Roll out in report-only, watch what it would block on real traffic, and tighten before you enforce.

RecommendationCopy Anchor Link

Connection-Allowlist-Report-Only: (response-origin "https://cdn.example"); report-to=connection-endpoint

Run the Report-Only header for at least a week first, as the Connection-Allowlist builder guide shows, so you see every connection the policy would block before anything breaks. Keep the CSP connect-src directive enforced too. It is the egress control for browsers that do not support Connection Allowlists.

ReportingCopy Anchor Link

A report-to=<name> parameter points at an endpoint declared in a Reporting-Endpoints header, and the browser emits the connection-allowlist report for each blocked or would-be-blocked connection. CentralCSP ingests that report alongside your CSP and other browser reports, so you can run Connection-Allowlist-Report-Only and watch the blocked connections across real traffic before enforcing. The Connection-Allowlist builder turns those reports into a list you review and deploy.

Browser supportCopy Anchor Link

Chrome and other Chromium-based browsers support the header from version 152, on desktop and Android, after an origin trial from version 148 to 151. Mozilla's standards position is positive, but Firefox does not implement it. Safari does not implement it, and WebKit has not published a position. The spec is a WICG Draft Community Group Report, not on the W3C standards track yet.

Chrome also runs a separate origin trial, from version 156 to 159, for embedded enforcement. It lets a page require a list on the iframes it embeds.

See alsoCopy Anchor Link

• connection-allowlist report
• Connection Allowlists, a network egress sandbox in the browser
• connect-src directive
• Reporting-Endpoints header
• Build a Connection-Allowlist from your reports

SourcesCopy Anchor Link

• WICG, Connection Allowlists
• WICG/connection-allowlists explainer
• Chrome Platform Status, Connection Allowlists
• Mozilla standards position on Connection Allowlists