How to Use Connection-Allowlist in Chrome 152

Target outcome: The website’s HTML response has a minimal allowlist that is tested in Report-Only mode before enforcement is enabled. This process is suitable for beginners who can modify a web server, reverse proxy, or CDN. You also need HTTPS, configuration access, and a preliminary list of APIs, CDNs, workers, and third-party services. Chrome 152 recorded Connection-Allowlist in the stable channel on August 25, 2026, and it applies to connections initiated by documents or workers (according to developer.chrome.com). This feature does not replace HTTPS, CSP, authentication, or server-side source-code protection.

What does Connection-Allowlist control?

Connection-Allowlist Connection-Allowlist is an HTTP response header containing a list of endpoints that a context is allowed to contact. The browser may block an endpoint that does not match the policy before a connection is established. The goal is to narrow unexpected communication channels—for example, when an injected script attempts to send data to an unfamiliar server.

The policy is associated with each context. A document’s header controls connections initiated by that document; a worker’s header controls the corresponding worker context. This header does not prevent users from navigating on their own, cannot remediate malicious code on the server, and does not address side channels such as inference through CPU or memory (according to wicg.github.io).

How does Connection-Allowlist differ from CSP?

CSP: classifies multiple resource types using directives such as script-src, style-src, img-src and connect-src; CSP is still required for content control and reducing XSS risk.
Connection-Allowlist: focuses on the set of endpoints that a document or worker is allowed to contact, rather than classifying resources only by type.
Combined: the two mechanisms complement each other. Do not remove CSP, CORS, CSRF protection, authentication, or authorization merely because you have added an allowlist.

Connection-Allowlist is not a replacement for a firewall: a firewall controls traffic at the server infrastructure layer, whereas this header imposes a constraint in the user’s browser.

Check access and infrastructure before making changes

Identify the layer that returns the HTML: record the website, reverse proxy, CDN, or web server that actually generates the final response. You need permission to modify this layer, not merely permission to edit the application source code.
Prepare an SSH session or server control panel: if you use SSH, run administrative commands in the server’s terminal; replace admin@example.com and example.com with the actual values. Do not paste commands with administrative privileges before checking the paths.
Check DNS and HTTPS: the domain name must point to the correct layer serving the website, the certificate must be valid, and the HTTPS port must be permitted by the firewall. Connection-Allowlist does not fix DNS, certificate, or routing problems.
Back up before making changes: save a copy of the Nginx, Apache, or CDN configuration together with the current allowlist. Record the configuration version and reload procedure so you can restore the previous state if the website fails.

Create a minimal allowlist

Do not start with a broad wildcard. Use DevTools, application logs, and integration documentation to create the following table:

Connection group	Example	How to decide
Same origin	`https://example.com`	Usually represented by the `response-origin`token.
Separate API	`https://api.example.com`	Add it only if the document or worker actually calls this API.
CDN	`https://cdn.example.com`	Cross-check the actual resource and hostname in the response.
Third-party services	Payments, maps, analytics	Confirm the connection flow, redirects, and type of data sent before allowing it.

Record endpoints called by Web Workers, Service Workers, WebSockets, WebRTC, or DNS prefetch if the application uses them. Do not automatically add every hostname found in the logs to the allowlist; an unfamiliar endpoint may come from an unnecessary library or injected code.

Write the header with the correct syntax

The header value is a Structured Field consisting of an inner list. The token response-origin represents the origin that returned the document; the remaining URL patterns are absolute strings. The specification also describes parameters such as redirects, webrtc and report-to.

Connection-Allowlist: (response-origin "https://api.example.com" "https://cdn.example.com")

This example allows the document to connect to the origin that provided it, as well as the specified API and CDN. The URLs in the example are placeholders: replace example.com with the actual hostname, while preserving the protocol, port, and URL pattern used by the application. Do not format it like a comma-separated CSP source list.

Test with Report-Only before blocking

Report-Only lets you observe violations without blocking connections. It is the safer option when the application uses SDKs, advertising, cross-origin sign-in, or workers that have not yet been fully inventoried.

Connection-Allowlist-Report-Only: (response-origin "https://api.example.com" "https://cdn.example.com")

If you need to collect reports, declare a reporting endpoint that you control:

Reporting-Endpoints: connection-errors="https://reports.example.com/connection"
Connection-Allowlist-Report-Only: (response-origin "https://api.example.com" "https://cdn.example.com"); report-to=connection-errors

Replace the reporting URL with the actual endpoint and protect it like an API that receives data from browsers. Reports may contain the context URL, the violating connection, the allowlist, and the status enforce or report; limit the logging of sensitive data.

Configure Nginx or Apache

Nginx

Perform this in the server or location block that returns the HTML. The configuration below is an example; retain your existing root, proxy, and SSL directives:

server {
    listen 443 ssl;
    server_name example.com;

    add_header Connection-Allowlist-Report-Only '(response-origin "https://api.example.com" "https://cdn.example.com")' always;

    # Giữ các chỉ thị root, proxy_pass và SSL hiện có ở đây.
}

Replace all three sample hostnames with the actual values. In the server's SSH terminal, check the syntax before reloading:

sudo nginx -t
sudo systemctl reload nginx

The expected result of the first command is syntax is ok and test is successful. If the check fails, do not reload; fix the configuration file and run sudo nginx -tagain. always causes the header to appear in multiple error responses, but a CDN or upstream cache may still remove or overwrite the header.

Apache HTTP Server

In the HTTPS VirtualHost or an appropriate directory configuration, enable the headers module before setting the header:

Header always set Connection-Allowlist-Report-Only "(response-origin \"https://api.example.com\" \"https://cdn.example.com\")"

Run this in the server's SSH terminal:

sudo a2enmod headers
sudo apachectl configtest
sudo systemctl reload apache2

The expected result is Syntax OK. On operating systems or distributions that use a different service name, replace apache2 with the actual Apache service name. If configtest fails, do not reload until the issue has been fixed.

Verify the response and real-world flows

Check the final response: run this in the client or server terminal, replacing the URL with the actual page:

curl -sSI https://example.com/ | grep -iE 'connection-allowlist|reporting-endpoints'

The correct header must appear after the final CDN, proxy, and redirect layers. If it does not, check where the header is set, the cache, and any rules that overwrite the response.

Check the Network panel: open Chrome DevTools, select Network, enable logging if necessary, reload the page, and observe requests to APIs, CDNs, worker scripts, and third-party services.
Read the reports: categorize necessary, unnecessary, and suspicious endpoints. Identify the library or code that creates each connection before adding it to the allowlist.
Check workers: confirm that the worker URL is the expected URL and that the fetch() calls made by the worker target only approved endpoints. Check the Service Worker separately if the application uses one.
Check redirects: run sign-in, OAuth callbacks, payments, file downloads, and real-time notifications. The current specification blocks redirects by default; enable the redirects parameter only after documenting every hop and assessing the risks.
Check WebRTC: if the application uses voice or video, verify STUN/TURN separately. WebRTC uses endpoint mechanisms distinct from HTTP requests and may currently be blocked by the policy by default.

Seeing the header through curl only confirms that the response contains the header; it does not prove that the entire application works correctly. Consider preparation complete only after the critical business flows and server logs produce the expected results.

Switch to enforce mode

After addressing valid reports, replace the Report-Only header with the enforcing header:

Connection-Allowlist: (response-origin "https://api.example.com" "https://cdn.example.com")

Deploy by page group or application version where possible. After reloading the web server, repeat the checks with curl, DevTools, sign-in, payments, file downloads, and background worker activity. If multiple policies apply, the connection must pass all corresponding policies; a stricter policy may still block a request even when CSP allows it.

Common errors and how to fix them

The page still connects to endpoints outside the list

Check whether you are seeing Connection-Allowlist or only seeing Connection-Allowlist-Report-Only. Then check the final response after redirects, caching, the CDN, and the Chrome version in use.

A valid API is blocked

Compare the actual URL with the pattern, including the scheme, hostname, port, and path. Also check requests originating from workers, iframes, and Service Workers, because each context may have its own policy.

Login or payment is broken

Check OAuth redirects or payment callbacks before opening a wildcard. List each trusted hop, assess the data passing through each one, and then adjust the redirects parameter or callback architecture.

WebRTC does not work

Check STUN/TURN and the webrtcparameter separately. Do not add a global wildcard as a quick fix; if you cannot yet identify the required endpoint, return to Report-Only while you investigate.

The header has a syntax error or is missing

The inner list requires parentheses, URL patterns are strings enclosed in double quotation marks, and response-origin is a token that must not be enclosed in quotation marks. Run nginx -t or apachectl configtest, then check the response through the CDN rather than checking only the source configuration file.

Rollback and security limitations

If a critical feature breaks, first restore the backed-up configuration. The minimum rollback is to change Connection-Allowlist back to Connection-Allowlist-Report-Only, check the syntax, reload the web server, and verify the response again. If the issue is severe, remove the enforce header from the layer that returns the HTML; do not remove HTTPS, CSP, authentication, or other protective mechanisms.

The header protects connections initiated by the context; it does not automatically block XSS, malware on the server, or unauthorized changes to response headers.
An allowlist does not replace authentication, authorization, CORS, CSRF protection, CSP, input validation, or a firewall.
A broad wildcard reduces the policy’s value. Prefer specific origins and hostnames, and expose a broad port or pattern only when there is a documented reason.
Connection Allowlists are still a Web Platform Incubator Community Group specification, not a W3C standard. Check behavior in the browsers and versions actually used by your users before treating this as the sole layer of protection (see github.com).

Implementation checklist

Identify the layer that returns the HTML, access permissions, DNS, HTTPS, the firewall, and the configuration recovery path.
List the endpoints used by the document, iframes, Web Workers, and Service Workers.
Add Connection-Allowlist-Report-Only with the minimum required list.
Run the configuration check, reload safely, verify the response after the CDN, and review the reports.
Test APIs, redirects, login, payments, file downloads, WebRTC, and background activity.
Switch to Connection-Allowlist, monitor errors, and keep a copy of the configuration for rollback.

The core principle is: allow as few endpoints as possible, observe with Report-Only first, and enable enforce only after testing workers and redirect flows.

Connection-Allowlist in Chrome 152: Limit Endpoints Without Breaking Your App