# Overview (/en/docs/platform/features/builders/connection-allowlist) The Connection-Allowlist builder writes a [Connection-Allowlist](/en/docs/web-security/policies/connection-allowlist) header from your own reports. You pick the reports to learn from, start from your own origin or from a list you paste, decide which reported destinations to allow, and copy the headers. The builder lives under each website, in the sidebar, as **Builders** > **Connection-Allowlist**. The same **Builders** menu holds the Content-Security-Policy and Permissions-Policy builders. It works on every plan, and every website role can use it. Any script on your pages can send data to a destination the list allows, so allow only the destinations you recognize. The builder's defaults allow every reported destination that is not noise, and a reported destination is not proof that your pages connect to it. A list from the API or the MCP tool applies the same defaults with no review, so check it the same way. Always deploy a new list with the `Connection-Allowlist-Report-Only` header first. Switch to `Connection-Allowlist` only once a week or more of reports shows that nothing your pages need would be blocked. ## What the Connection-Allowlist builder produces [#what-the-connection-allowlist-builder-produces] The builder ends with two response headers, ready to paste into your server or content delivery network (CDN) configuration. A [`Reporting-Endpoints`](/en/docs/web-security/reporting-api/headers/reporting-endpoints) header points reports at your website's CentralCSP endpoint. A `Connection-Allowlist-Report-Only` header carries the list, or `Connection-Allowlist` once you switch to enforce mode. The list holds `response-origin`, the origin each page is served from, and one entry per destination you allow. A site with three or more reported subdomains can share one `https://*.` pattern instead of an entry for each. The value always ends with `report-to=centralcsp`, so the browser sends its reports to CentralCSP: ```http Connection-Allowlist-Report-Only: (response-origin "https://*.example.com" "https://api.example.net"); report-to=centralcsp ``` The builder does not save or deploy anything. It gives you the headers, and you add them to your site. Each export, the headers as TXT or the review table as CSV, is recorded in the [audit log](/en/docs/platform/security/audit-log#exports). ## How it works [#how-it-works] The builder works in four steps. Each step reuses the answer of the one before it. 1. **Period**: Choose which days of reports to learn from, up to the last 30. 2. **Starting policy**: Start from **Only your own origin**, which is `(response-origin)`, or paste the list you send today. 3. **Review destinations**: Choose whether the browser may follow redirects, then allow or reject each reported destination. Every destination starts decided for you, and noise starts rejected. 4. **Deploy**: Pick report-only or enforce mode, and copy the headers. The Connection-Allowlist builder on the Period step, with 7 days selected on the report chart and the Reports, Destinations, and Look like noise counters ## Where the data comes from [#where-the-data-comes-from] The builder reads the [Connection-Allowlist reports](/en/docs/web-security/reporting-api/reports/connection-allowlist) your website already collects. Each report names a connection the browser blocked, or would have blocked in report-only mode. The builder turns each blocked URL into its origin, the destination you can allow, and counts how often browsers reported it. WebRTC connections have no destination, so they are one row of their own. Allowing that row sets `webrtc=allow` on the list. Destinations that belong to a browser extension are set aside, because an extension is not your site's traffic. For how the builder groups destinations, flags noise, and picks its defaults, refer to [Builder decision rules](/en/docs/platform/features/builders/connection-allowlist/how-it-decides). ### Why it never starts from a reported list [#why-it-never-starts-from-a-reported-list] The CSP builder can start from the policy your site serves, because each CSP report carries that policy. The Connection-Allowlist builder never starts from a list read out of the reports. Anyone who knows your reporting endpoint can send a report to it, so a list found in reports could be forged, and starting from it would allow destinations an attacker chose. The builder starts from your own origin, or from the list you paste yourself. The same caution applies to each reported destination. Review what you allow in the [Review destinations](/en/docs/platform/features/builders/connection-allowlist/review-destinations) step. ## Browser support [#browser-support] Only Chromium-based browsers support Connection-Allowlist. Other browsers ignore the header, so keep the Content Security Policy [`connect-src`](/en/docs/web-security/policies/content-security-policy/directives/connect-src) directive as your egress control for them. The deploy step repeats this note. For the current support status, refer to [Connection-Allowlist browser support](/en/docs/web-security/policies/connection-allowlist#browser-support). ## Use it from the API and the MCP server [#use-it-from-the-api-and-the-mcp-server] The REST API builds the same list without the wizard. The **Build a recommended Connection-Allowlist** endpoint takes an optional period and an optional starting list. Without a starting list, it starts from `(response-origin)`. It returns the list as a header value in `policy`, and the `Reporting-Endpoints` value to send with it in `reportingEndpoints`. It applies the same defaults as the dashboard. Refer to the [API reference](/en/docs/api-mcp/api). The [Model Context Protocol (MCP) server](/en/docs/api-mcp/mcp) exposes that endpoint as the `build_recommended_connection_allowlist` tool. ## Next steps [#next-steps] * [Get started](/en/docs/platform/features/builders/connection-allowlist/get-started) * [Review destinations](/en/docs/platform/features/builders/connection-allowlist/review-destinations) * [Builder decision rules](/en/docs/platform/features/builders/connection-allowlist/how-it-decides) * [Builders overview](/en/docs/platform/features/builders) * [Connection-Allowlist reports](/en/docs/platform/monitoring/connection-allowlist) * [Connection Allowlists, a network egress sandbox in the browser](/en/blog/connection-allowlists-network-egress)