Chrome 152 Adds Connection Allowlists and New Controls

Chrome 152 ships new controls for outbound connections

Chrome 152 stable landed on August 25, 2026, and the release applies across 5 platforms: Android, ChromeOS, Linux, macOS, and Windows. The headline for security teams is Connection Allowlists. It gives sites a browser-level way to restrict where documents and workers can connect.

That matters because outbound requests are one of the easiest paths for data to leave a page. A compromised script, a risky dependency, or a misconfigured app can all turn a normal browser session into an exfiltration channel. Chrome 152 does not solve that problem by itself, but it does add a control point that web apps and platform teams can finally reason about at the browser boundary.

If you have been tracking broader browser hardening work, this release fits the same pattern as other recent Chrome changes that push more policy into the browser itself. It sits naturally alongside earlier work on browser behavior and security controls, including Chrome 152 Adds CPU Performance API and Allowlists and Browsers Before AI vs. Now: What Actually Changed for Users.

---

How Connection Allowlists work

Connection Allowlists restrict connections initiated through the Fetch API or other web platform APIs from a document or worker. The browser checks destinations against an authorized list before establishing the connection. In the WICG spec, that list arrives through an HTTP response header, and the spec defines both an enforced header and a report-only variant.

The response header format is simple in concept but strict in effect. The Connection-Allowlist header contains a list of serialized URL pattern strings that define the endpoints a context may connect to. The Connection-Allowlist-Report-Only header uses the same parsing rules, but it only reports violations instead of blocking traffic. The spec also allows the token response-origin, which means the browser can treat the response’s own origin as an allowed pattern.

That design goal is explicit in the spec. It says this control is needed to limit how users’ data can flow through the user agent, including mitigating exfiltration attacks, and to preserve control over a site’s architecture and dependencies. In plain terms: if your app should only talk to a short list of domains, the browser can now help enforce that list.

The spec also defines how policy relationships are compared. A candidate allowlist satisfies a requirement only if it is a subset of the requirement allowlist. That matters for enterprise policy, application frameworks, and any layered setup where one component wants tighter rules than the base platform.

For teams already doing browser hardening work, this is a cleaner model than trying to infer intent from logs after the fact. If you are wondering how this fits into a larger application security review, our AI Code Security Audit service is the right place to start when you need a concrete assessment of browser-facing code and request boundaries.

---

New browser features in Chrome 152

Connection Allowlists are the security headline, but Chrome 152 also ships several platform features that developers will notice quickly.

One update extends CSSPseudoElement support beyond the 3 pseudo-elements already defined for ::after, ::before, and ::marker. The release adds ::backdrop, ::scroll-marker, and ::view-transition. That gives developers better hooks for dialogs, scroll stats, and view transitions without custom workaround code.

Chrome 152 also adds relative alpha colors. This feature changes only 1 channel (alpha) of an origin color, so developers can derive transparency from an existing value instead of rebuilding the whole color.

Another change renames the app-region CSS property to window-drag. The new name standardizes the behavior, changes the value names to 2 value names — move and none — and adds explicit inheritance behavior.

The release also exposes autocorrect as a global HTML attribute and reflects it on HTMLElement. That is a small change on paper, but it is the kind of API cleanup that makes browser behavior easier to inspect and reason about.

Finally, OpaqueRange now enables operations on form-control text ranges, including 3 example operations: getBoundingClientRect(), getClientRects(), and integration with the CSS Custom Highlight API. That will matter for inline suggestions, highlights, and anchored popovers.

---

Security and policy changes in Chrome 152

Chrome 152 includes more than one security-related change, and some of them affect operational behavior rather than pure code paths.

For users of Safe Browsing Enhanced protection, Chrome now shows a bypassable warning popup when visiting sites with signals indicating they are potentially malicious. That warning is an additional layer on top of existing interstitial warnings for confirmed malicious websites. It does not replace the hard stop, but it does create earlier friction for risky visits.

The release also changes notification behavior on macOS. When a Progressive Web App is installed on macOS, notifications are attributed to the PWA itself rather than Google Chrome. Chrome also no longer supports the requireInteraction field for notifications on macOS, and the Badging API requires notification permissions for the app badge to appear.

That is a useful reminder that browser features often arrive as policy changes first and developer-facing features second. If you ship a PWA, this is not just a cosmetic update. It changes how users see your app in Notification Center and how your badge flows depend on permission state.

Chrome 152 also starts a deprecation trial for client-side XSLT. The goal is to give sites additional migration time. And it removes the Private Aggregation API along with related Privacy Sandbox APIs. If your product still depends on those paths, this release is a signal to confirm what remains in your stack before the old APIs disappear from your assumptions.

---

What Connection Allowlists mean for web app security

The security value of Connection Allowlists is not that they create a new network stack. It is that they make intended outbound behavior explicit.

That helps in three places.

First, it limits accidental exfiltration. If a document or worker should only talk to a specific service, the browser can reject everything else before the request leaves the page.

Second, it improves dependency control. Modern apps often pull data, telemetry, media, and remote configuration from many endpoints. When those endpoints are known and few, an allowlist is easier to audit than a broad outbound policy.

Third, it gives defenders a clearer story during incident response. Instead of asking whether a page could connect outward in theory, you can inspect whether the browser was allowed to make that connection at all.

The spec also makes its scoping clear by defining two disposition modes, 2 redirect modes and 2 WebRTC modes. That tells you the design is not limited to a single transport path. It is trying to shape broader connection behavior across the web platform.

This is also where the report-only mode matters. A team can observe violations first, then move to enforcement after it has tuned the list. That is the same rollout pattern many security teams prefer for CSP and other browser policies: measure, then block.

If you are already thinking about how to audit this kind of browser policy across an app estate, the question is not just “Can Chrome enforce it?” It is “Who owns the endpoint list, how is it reviewed, and how do we know a worker or embedded document did not drift outside policy?”

---

How to adopt Connection Allowlists safely

Start with the smallest useful scope. A good allowlist should match real application behavior, not a guessed ideal. Use the report-only header first so you can see which requests would fail without breaking production traffic.

Then map the allowed endpoints to owners. Every entry should have a reason to exist. If an endpoint only supports one feature, tie it to that feature and remove it when the feature is retired.

Pay close attention to workers. The Chrome release notes explicitly say the control applies to connections initiated through the Fetch API or other web platform APIs from a document or worker. That means background code can trigger the same policy path as front-end code.

Also watch for redirect behavior and WebRTC behavior. The spec gives each of those 2 modes, so you should verify how your app behaves when a connection path changes under the hood.

For teams already investing in browser-side policy, pair this with code review checks and runtime logs. A browser policy is strongest when you can confirm the policy source, the request destination, and the application owner in one place.

---

Developer takeaways for Chrome 152

Chrome 152 is not a single-purpose release. It brings new browser features, platform cleanup, and a real outbound connection control in the same milestone.

The most important security change is Connection Allowlists. It gives web apps an enforced browser policy for outbound requests, with a report-only mode to ease rollout. The key operational question is whether your application really needs the wide-open connection pattern most sites still use.

If the answer is no, start by inventorying every endpoint your page and workers can reach. Turn on reporting. Then tighten the allowlist until the browser rejects everything that is not essential.

If the answer is yes, you still need to document why. Broad network access is often a convenience, not a requirement. Chrome 152 gives you a chance to prove that difference.

The practical takeaway is simple: review your outbound request paths, test Connection Allowlists in report-only mode, and remove any dependency that only exists because the browser previously let it through.