One response header names the destinations your site is allowed to connect to. The browser refuses everything else before the connection is opened — including connections made by code you did not write. Report URI collects the reports, so you can see what a list would refuse before you enforce one.
Every script your page loads inherits the same reach your own code has. An analytics tag, a chat widget, a tag manager, a dependency four levels deep in someone else's bundle — each one can open a connection to any destination it chooses, and the browser will carry it. A Connection Allowlist inverts that: you name the destinations, and the browser refuses the rest before anything leaves the device.
You chose the vendor. You did not choose every endpoint their script talks to, and you will not be told when that changes. The connection is made from your visitors' browsers, carrying whatever was on the page at the time.
Permitting a host permits all of it. If a vendor's domain is on your list for one API, it is on your list for every other path that domain serves — including whichever one an attacker finds most convenient.
WebSockets, WebTransport, WebRTC, DNS prefetch, navigations and redirects are all ways data leaves a page. Controls aimed at subresource loading govern some of them weakly and others not at all.
Report URI collects Connection Allowlist reports straight from your visitors' browsers, so the list you enforce is built from what your site really does — not from what you think it does.
Each report carries the page that made the attempt and the destination that was refused, so an unfamiliar host is immediately traceable to the page it appeared on. Run in report-only first and the reports become your inventory: the destinations you expected, the ones you had forgotten, and the ones that should not be there at all.
Learn more about the Reporting API →Destinations are written as URL patterns, so a list can permit https://api.example.com/v1/* without permitting everything else that host serves. A vendor you trust for one endpoint stays trusted for that one endpoint. That granularity is the practical difference between this and an origin-level connection control.
Send Connection-Allowlist-Report-Only and the browser evaluates your list, reports what it would have refused, and lets every connection through as normal. Your checkout still completes and your analytics still report while you work through whatever the reports turn up — and a run that turns up nothing is a perfectly good result.
One header. No code. Connection Allowlist reports start arriving from your first visitor.
30-day free trial · One header · No code · Cancel anytime
A Connection Allowlist is evaluated before the connection is established, whatever opened it. That covers the channels a subresource-loading control was never designed to reach, and it applies inside workers as well as in the document.
| Channel | What the allowlist does |
|---|---|
| Fetch and XHR | Checked against your list before the request is sent |
| WebSockets and WebTransport | Long-lived channels are checked the same way as a one-off request |
| WebRTC | Refused by default; reported with the literal value webrtc, as there is no host to name |
| Redirects | Refused by default when a permitted destination redirects to one that is not, closing the obvious way around a list |
| Navigations and DNS prefetch | Evaluated too, so a destination cannot be reached by a route other than a request |
| Workers | The policy applies inside workers, not only in the document that set it |
The browser enforces all of this. Nothing runs on your servers, and nothing sits in the path of your traffic.
Connection Allowlist is a browser standard, shipped in Chrome 152, and its reporting is built in alongside it. The data comes from real sessions, which matters here more than most: the connections least likely to be noticed are the ones made behind a login, during a checkout, or only for certain regions — exactly what a crawler never sees.
Start in report-only and nothing changes for your visitors. Add the header, point it at your reporting endpoint, and the list of destinations begins building from your first visitor.
Connection-Allowlist-Report-Only: (response-origin
"https://api.example.com/v1/*");
report-to=default
Reports are delivered over the Reporting API, so you will also need a Report-To group pointing at your Report URI endpoint. Your subdomain and the exact header are on your Setup page once you have an account.
The two halves of the same problem. Data Watch monitors where your site sends data and alerts you when a new destination appears, which is how you find out something changed — on a site with no allowlist deployed, and across browsers that do not implement one. A Connection Allowlist takes the destinations you have confirmed and has the browser refuse the rest outright.
Running both is the useful arrangement: Data Watch keeps working everywhere and keeps telling you what is new, while the allowlist turns everything you have already decided about into something the browser enforces on your behalf.
A Connection Allowlist governs where your page is allowed to send data. It does not decide what is allowed to run in the first place, and it will not tell you when a script you already permitted quietly changes — it is the egress layer, and it works alongside the rest.
| Connection Allowlist does | Pairs with |
|---|---|
| Refuses connections to destinations you did not name | CSP for execution control — deciding what is allowed to run at all |
| Reports every destination a list would refuse | Data Watch for egress monitoring — alerting on a new destination wherever a list is not yet deployed |
| Controls where data may go, path by path | Script Watch for dependency visibility — knowing when your third parties change |
| Applies in documents and workers alike | Policy Watch for header integrity — detecting when the header itself changes |
Together, these form the browser-native security layer that sits between your application and the code executing around it.