# Connection Allowlists, a network egress sandbox in the browser (/en/blog/connection-allowlists-network-egress) Most client-side defenses try to stop bad code from running. Connection Allowlists take the opposite angle: assume the code runs, and make sure it has nowhere to send your data. A new browser header lets a page declare the exact set of destinations it is allowed to connect to, and the browser blocks every other outgoing connection, through any channel. A leak through a font request is treated as seriously as one through `fetch`. Connection Allowlists is an early WICG proposal. Chrome has run it as an origin trial and intends to ship it, while Firefox and Safari have not signalled support. Treat it as something to pilot in report-only, not to depend on in production. ## The problem it solves [#the-problem-it-solves] A Content Security Policy stops most injected scripts from executing. But a script that does run, a compromised dependency, a rogue tag, AI-generated code you did not review, can still phone home: post stolen form data to an attacker origin, open a WebSocket, or smuggle bytes out in an image URL. Controlling that egress with CSP means juggling `connect-src`, `img-src`, `font-src`, and more, each a separate directive, and even then CSP cannot cover WebRTC or redirects cleanly. Connection Allowlists reframe the problem around the destination, not the request type. You list where the page may connect, and the browser denies everything else at the network level. ## How it works [#how-it-works] You send a `Connection-Allowlist` response header listing the destinations the page may reach. Anything not on the list is blocked, including fetch, WebSocket, WebRTC, navigation, redirects, and subresource loads. ```http Reporting-Endpoints: connection-endpoint="https://.report.centralcsp.com" ``` ```http Connection-Allowlist: (response-origin "https://*.example.com" "https://cdn.example"); report-to=connection-endpoint ``` Each entry is a [URL Pattern](https://developer.mozilla.org/en-US/docs/Web/API/URL_Pattern_API), so subdomains and wildcards use that grammar. The `response-origin` token adds the serving origin automatically. Two things are blocked by default and you opt back in only if you need them: redirects (`redirects=allow`) and WebRTC (`webrtc=allow`), both common exfiltration paths. The full header syntax, values, and the report payload are in the [Connection-Allowlist reference](/en/docs/web-security/policies/connection-allowlist). ## Roll it out in report-only first [#roll-it-out-in-report-only-first] Just like CSP, there are two headers, and you start with the report-only one so a too-strict list reports instead of breaking the page. ```http Connection-Allowlist-Report-Only: (response-origin "https://*.example.com"); report-to=connection-endpoint ``` The browser blocks nothing and sends a [`connection-allowlist` report](/en/docs/web-security/reporting-api/reports/connection-allowlist) for every connection it would have blocked. Collect those from real traffic, confirm each blocked destination is either one to add or one you are glad to deny, then move the policy to the enforcing `Connection-Allowlist` header. ```mermaid flowchart LR A["Connection-Allowlist-Report-Only"] --> B["Collect reports
from real traffic"] B --> C["Add the destinations
you actually need"] C --> D["Enforce with
Connection-Allowlist"] ``` ## How it compares to CSP connect-src [#how-it-compares-to-csp-connect-src] This is not a CSP replacement. The [`connect-src`](/en/docs/web-security/policies/content-security-policy/directives/connect-src) directive is stable, widely supported, and the egress control to use today. Connection Allowlists are the experimental next layer: one deny-by-default policy that spans every request type, uses URL Pattern syntax, and covers WebRTC and redirects that `connect-src` does not. Ship a strong CSP now, and pilot Connection Allowlists in report-only to see where the egress layer would help. ## Where CentralCSP fits [#where-centralcsp-fits] CentralCSP is built on the browser Reporting API and ingests every report type the browser sends. A `connection-allowlist` report lands in the same pipeline as your CSP, NEL, and COOP/COEP reports. Point `Connection-Allowlist-Report-Only` at your CentralCSP endpoint and you can watch blocked and would-be-blocked connections across real traffic, grouped by destination, the same report-only-first workflow you already run for CSP. For the supply-chain side of the same problem, see [what Magecart and formjacking are](/en/blog/magecart-formjacking-detection) and the [script inventory](/en/docs/platform/features/script-inventory) that tracks what runs on your pages. [Start free](/register) to collect the reports. Reported outbound connections grouped by connection type and origin, each with its enforced or report-only disposition ## Next steps [#next-steps] * Read the [Connection-Allowlist header reference](/en/docs/web-security/policies/connection-allowlist). * See the [connection-allowlist report fields](/en/docs/web-security/reporting-api/reports/connection-allowlist). * Lock down egress today with [connect-src](/en/docs/web-security/policies/content-security-policy/directives/connect-src). ## Sources [#sources] * [WICG, Connection Allowlists](https://wicg.github.io/connection-allowlists/) * [Chrome for Developers, Connection Allowlists origin trial](https://developer.chrome.com/blog/connection-allowlists-origin-trial) * [MDN, URL Pattern API](https://developer.mozilla.org/en-US/docs/Web/API/URL_Pattern_API) ## Related [#related] * [What Magecart is, and how to detect a formjacking skimmer](/en/blog/magecart-formjacking-detection) * [Permissions-Policy explained](/en/blog/permissions-policy-explained) * [What is NEL, network error logging from the browser](/en/blog/what-is-nel-network-error-logging)