← Chrome 147 reference

v147 · stepped rollout · security · network

Local network access restrictions

Chrome 147 continues a stepped rollout of Local Network Access (LNA) restrictions, requiring user permission before public websites can send subresource requests (fetch, XHR, WebSockets, WebTransport) to local and private IP addresses. The permission model prevents drive-by attacks against routers, printers, smart home devices, and internal services on the same LAN.

Breaking change for some deployments Sites that make cross-origin requests to private IP ranges (192.168.x.x, 10.x.x.x, 172.16–31.x.x, localhost) without explicit user permission will start to fail. Enterprise environments with intranet tooling are most affected.

at a glance

Status in Chrome 147Stepped rollout (expanding to more users)
Feature rollout startedChrome 123 (subresource fetch/XHR); Chrome 147 (WebSockets, WebTransport, Service Worker)
Request types coveredFetch, XHR, WebSockets, WebTransport, WindowClient.navigate()
Permission mechanismBrowser permission prompt; enterprise policies for allowlists
SpecWICG Local Network Access specification
ChromeStatus5152728072060928 — Local network access restrictions
Source: Chrome for Developers — New permission prompt for Local Network Access

Rollout disagreement, both sides reported rather than resolved: this page records the rollout as started in Chrome 123 (with Chrome 147 adding WebSockets, WebTransport and Service Worker coverage), while the ChromeStatus record for feature 5152728072060928 reports desktop 142 with status “In development” (fetched 2026-10-06). A second ChromeStatus feature id previously cited here (5152728072060608) no longer resolves, so its dead link was removed.

what is local network access?

LNA is a web security boundary: it prevents web pages served from public origins (e.g. https://example.com) from making requests to private/local IP addresses without the user's explicit knowledge. This matters because devices on the local network — home routers, NAS drives, printers, smart home hubs — typically have no authentication and assume incoming requests come from trusted local clients. A malicious public page that can silently fetch http://192.168.1.1/admin can attack those devices.

Chrome enforces LNA by requiring a preflight check and (when the page is not served from a secure context that is itself local) a user permission prompt before the browser sends such requests.

Source: Chrome for Developers — Local Network Access

what Chrome 147 adds

Chrome 147 extends LNA restrictions to three additional request types that were previously uncovered:

Request typeChrome 147 changeDetails
WebSocketsPermission prompt requiredWebSocket LNA page
WebTransportPermission prompt requiredWebTransport LNA page
Service Worker WindowClient.navigate()Blocked for local addressesService Worker LNA page
Source: chromestatus.com/feature/5152728072060928

migration

Sites affected by LNA restrictions have several options:

Source: Chrome for Developers — Local Network Access

browser support

BrowserLocal Network Access permission status
ChromeThis page describes a stepped rollout beginning with fetch/XHR, then extending to WebSockets, WebTransport and Service Worker WindowClient.navigate() in Chrome 147. The cited ChromeStatus record instead lists desktop 142 as “In development”; see the rollout disagreement above.
EdgeThis permission model is not established by the cited sources.
FirefoxThis permission model is not established by the cited sources.
SafariThis permission model is not established by the cited sources.

Do not infer the same local-network prompt or request-type coverage in other browsers from a Chrome milestone or the WICG proposal.

Sources: ChromeStatus feature 5152728072060928; Chrome for Developers — Local Network Access.

see also