Connection-Allowlist

A connection-allowlist report tells you that a page tried to open a connection to a destination its Connection-Allowlist did not permit. In report-only mode, it shows what a policy would block before you enforce it. Under enforcement, it records what the browser blocked.

When the browser sends itCopy Anchor Link

The browser sends a report when a document or worker under a Connection-Allowlist or Connection-Allowlist-Report-Only header makes a connection that the allowlist does not match. The check covers these connections:

• Fetches and subresources, such as scripts, images, fonts, beacons, and EventSource streams
• Navigations, iframes, and popups opened with window.open()
• prefetch, preconnect, and dns-prefetch hints
• WebSocket and WebTransport connections
• WebRTC connections

The browser sends no report in these cases:

• The URL uses a local scheme, such as data: or blob:. Local URLs never reach the network.
• The header sets webrtc=allow and the connection is WebRTC.
• The header sets redirects=allow and the request was redirected.

Two body shapesCopy Anchor Link

The report arrives in the standard application/reports+json envelope. The spec lists four body fields on every report: url, connection, allowlist, and disposition. Chrome sends all four only for WebRTC.

For every other connection, Chrome sends only connection and disposition. The page that made the connection is the envelope url. This example shows a blocked fetch() in report-only mode:

{
  "type": "connection-allowlist",
  "age": 6,
  "url": "https://shop.example.com/checkout",
  "user_agent": "Mozilla/5.0 ... Chrome/154.0.0.0 Safari/537.36",
  "body": {
    "connection": "https://collect.example.net/data?token=abc",
    "disposition": "report"
  }
}

For a WebRTC connection, connection holds the string webrtc, and the body adds url and allowlist. This example shows an enforced block:

{
  "type": "connection-allowlist",
  "age": 12,
  "url": "https://shop.example.com/support",
  "user_agent": "Mozilla/5.0 ... Chrome/154.0.0.0 Safari/537.36",
  "body": {
    "url": "https://shop.example.com/support",
    "connection": "webrtc",
    "allowlist": ["https://shop.example.com"],
    "disposition": "enforce"
  }
}

Chromium sends both shapes, built in two places: the network service and the browser process send two fields, and the renderer sends four.

Field referenceCopy Anchor Link

The body holds these fields:

The browser removes the fragment and any credentials from connection. For reports without a body url, read the page from the envelope url. In allowlist, the response-origin token appears as the page origin it stands for.

How to read the connection fieldCopy Anchor Link

The connection value depends on the kind of connection:

Chrome sends long URLs whole. A capture of a URL with more than 3,000 characters arrived unshortened.

How to receive itCopy Anchor Link

Declare an endpoint with a Reporting-Endpoints header, then point the policy at it with the report-to= parameter. The Connection-Allowlist builder turns these reports into a list you review and deploy.

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

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

What it tells you about securityCopy Anchor Link

A connection-allowlist report names a destination your page tried to reach that you never authorized. That is the signal of an exfiltration attempt, or of a third party reaching somewhere unexpected. It is the same supply-chain risk that script inventory and Content Security Policy (CSP) reporting surface, at the network-egress layer.

GotchasCopy Anchor Link

Watch for these differences when you parse the reports:

• The page is in the envelope. Do not expect body.url or body.allowlist. Only WebRTC reports carry them.
• WebSockets arrive as https:. The browser converts ws: and wss: to http: and https: before it checks the allowlist, and it reports the converted URL. A report that names a wss: URL did not come from Chrome. For how to list them, refer to WebSocket destinations.
• Your own origin can appear. With redirects blocked, the browser reports the URL the page requested, not where the redirect led. A report that names your own origin usually means the browser blocked a redirect.
• Some connections report twice. Chrome sends two identical reports for each blocked navigation, iframe, popup, and preconnect. A duplicate looks the same as a second real attempt, so do not treat report counts as exact connection counts.
• Anyone can send a report. A reporting endpoint is public, so a report can be forged. Check a destination before you allow it.

Browser supportCopy Anchor Link

Chrome and other Chromium-based browsers enforce the header and send this report from version 152, on desktop and Android. Chrome ran an origin trial from version 148 to 151. Firefox and Safari do not implement it. The spec is a Draft Community Group Report of the Web Platform Incubator Community Group (WICG), not a W3C standard.

See alsoCopy Anchor Link

• Connection-Allowlist header
• Connection Allowlists, a network egress sandbox in the browser
• csp-violation report
• Build a Connection-Allowlist from your reports
• Connection-Allowlist reports in CentralCSP
• The report delivery format

SourcesCopy Anchor Link

• WICG, Connection Allowlists
• Chrome Platform Status, Connection Allowlists
• Chromium, network_context.cc
• Chromium, connection_allowlist_violation_report_body.cc
• MDN, Reporting-Endpoints header