# Connection-Allowlist (/en/docs/web-security/policies/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.

<Callout type="warn" title="Experimental, origin trial">
  Connection Allowlists is a WICG Draft Community Group Report (last updated June 2026), available through an in-progress Chrome origin trial only. Nothing has shipped by default, and no other engine has signaled support. The syntax and report shape can still change.
</Callout>

During the origin trial, run the Report-Only header first, with the endpoint name
declared in [`Reporting-Endpoints`](/en/docs/web-security/reporting-api/headers/reporting-endpoints):

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

## How it works [#how-it-works]

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.
Everything else, fetch, WebSocket, WebRTC, navigation, redirects, fonts, images, is
blocked at the network level.

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

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

The value is a structured-field inner list
([RFC 9651](https://www.rfc-editor.org/rfc/rfc9651)). Each entry is either the `response-origin`
token or a quoted [URL Pattern](https://developer.mozilla.org/en-US/docs/Web/API/URL_Pattern_API)
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](/en/docs/web-security/policies/content-security-policy/values/csp-host-source)
grammar.

## Values [#values]

| Value                                 | Status          | Meaning                                                                                                                                 |
| ------------------------------------- | --------------- | --------------------------------------------------------------------------------------------------------------------------------------- |
| `response-origin`                     | 🧪 Experimental | Token that adds the origin serving the response to the allowlist automatically.                                                         |
| `"https://..."`                       | 🧪 Experimental | A quoted URL Pattern for an allowed destination.                                                                                        |
| `report-to=<name>`                    | 🧪 Experimental | Names a [`Reporting-Endpoints`](/en/docs/web-security/reporting-api/headers/reporting-endpoints) endpoint to receive violation reports. |
| `redirects=block` / `redirects=allow` | 🧪 Experimental | Whether to follow redirects. Default is `block`.                                                                                        |
| `webrtc=block` / `webrtc=allow`       | 🧪 Experimental | Whether to allow WebRTC connections. Default is `block`.                                                                                |

Every value is experimental: the whole header exists only behind the Chrome origin
trial.

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

## Enforce and report-only [#enforce-and-report-only]

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](/en/docs/web-security/reporting-api/reports/connection-allowlist)
for each connection it would have blocked.

## How it relates to CSP connect-src [#how-it-relates-to-csp-connect-src]

This does not replace your Content Security Policy. The CSP
[`connect-src`](/en/docs/web-security/policies/content-security-policy/directives/connect-src)
directive is stable and widely supported, and it is the egress control to ship
today. Connection Allowlists is the experimental egress layer arriving next, 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](/en/docs/web-security/policies/content-security-policy/directives/webrtc)
is spec-only, with no browser support), redirects, and navigations. Use `connect-src` now; consider Connection Allowlists when you want a
single deny-by-default egress policy.

## What it protects against [#what-it-protects-against]

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 avoid [#insecure-configurations-to-avoid]

<Callout type="warn">
  A broad pattern such as `https://*` allows any HTTPS destination and defeats the allowlist, the same mistake as `connect-src *` in CSP. List specific origins, and turn `redirects=allow` or `webrtc=allow` on only when a feature genuinely needs them.
</Callout>

## Known bypasses and limitations [#known-bypasses-and-limitations]

Experimental and Chromium-only, so it protects users only on browsers that
implement it and have the origin trial enabled. It governs the destination of
connections, not what a script does in the page, so it complements rather than
replaces CSP and input handling.

## Risks [#risks]

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.

## Recommendation [#recommendation]

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

If you want to evaluate it, join the Chrome origin trial and run the Report-Only
header first, so you see every connection the policy would block before anything
breaks. Keep the CSP [`connect-src`](/en/docs/web-security/policies/content-security-policy/directives/connect-src)
directive as your enforced egress control in the meantime; it is the stable,
cross-browser mechanism until Connection Allowlists ships by default somewhere.

## Reporting [#reporting]

A `report-to=<name>` parameter points at an endpoint declared in a
[`Reporting-Endpoints`](/en/docs/web-security/reporting-api/headers/reporting-endpoints) header,
and the browser emits the
[`connection-allowlist` report](/en/docs/web-security/reporting-api/reports/connection-allowlist)
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.

## Browser support [#browser-support]

An in-progress Chrome origin trial only; nothing has shipped by default, and no other
engine has signaled support. The spec is a WICG Draft Community Group Report (last
updated June 2026), not on the W3C standards track yet.

## See also [#see-also]

* [connection-allowlist report](/en/docs/web-security/reporting-api/reports/connection-allowlist)
* [Connection Allowlists, a network egress sandbox in the browser](/en/blog/connection-allowlists-network-egress)
* [connect-src directive](/en/docs/web-security/policies/content-security-policy/directives/connect-src)
* [Reporting-Endpoints header](/en/docs/web-security/reporting-api/headers/reporting-endpoints)

## Sources [#sources]

* [WICG, Connection Allowlists](https://wicg.github.io/connection-allowlists/)
* [WICG/connection-allowlists explainer](https://github.com/WICG/connection-allowlists)
* [Chrome for Developers, Connection Allowlists origin trial](https://developer.chrome.com/blog/connection-allowlists-origin-trial)