v147 · shipped · security · websocket

Local network access restrictions for WebSockets

Chrome 147 extends Local Network Access (LNA) protections to WebSocket connections. Public websites now need explicit user permission before connecting via WebSocket to local or private IP addresses (loopback, LAN). This prevents silent cross-origin requests to devices on the user's private network.

Breaking change WebSocket connections from public websites to local addresses (localhost, 192.168.x.x, 10.x.x.x, etc.) now trigger a permission prompt in Chrome 147 and Edge 147. Existing apps that relied on silent WebSocket connections to local services will stop working until users grant permission — or until the site obtains a per-origin policy exemption.

at a glance

Shipped in	Chrome 147, Edge 147 (desktop, Android)
Status	Enabled by default
Flag	`chrome://flags/#local-network-access-check-websockets`
Spec	WICG Local Network Access spec
ChromeStatus	5197681148428288 — Local network access restrictions for WebSockets

why it exists

Private network devices (printers, routers, smart home hubs, development servers) often lack authentication and CORS headers, making them easy targets. A malicious public website could silently open a WebSocket to ws://192.168.1.1 and interact with a home router's local admin interface without the user's knowledge. Chrome already gated subresource fetches (HTTP/HTTPS) to local addresses behind LNA checks; Chrome 147 closes the same gap for WebSocket connections.

Source: blink-dev Intent to Ship — Local network access restrictions for WebSockets, April 2026.

what changes

WebSocket connection attempts from secure public pages to local/private addresses now require a user permission grant. The browser shows a permission prompt; if the user denies (or no prompt is shown because the site is not secure), the WebSocket connection is blocked.

Affected address ranges

Address range	Examples
Loopback	`127.0.0.1`, `localhost`, `::1`
Private (RFC 1918)	`10.x.x.x`, `172.16–31.x.x`, `192.168.x.x`
Link-local	`169.254.x.x`, `fe80::/10`

Requirements for the connection to proceed

The page must be served over HTTPS (secure context).
For WebSocket connections from <iframe> content, the iframe must include allow="loopback-network".
The user must grant the Local Network Access permission when prompted.

Source: Chrome for Developers blog — Local Network Access permission prompt, April 2026.

enterprise policy

Enterprise deployments can bypass the restriction via Chrome policies:

Policy	Effect
`LocalNetworkAccessAllowedForUrls`	Origins allowed to connect to local network without a prompt.
`LocalNetworkAccessBlockedForUrls`	Origins blocked from connecting to local network.
`LocalNetworkAccessRestrictionsTemporaryOptOut`	Temporarily disables the restriction enterprise-wide during rollout.

Source: Chrome enterprise release notes, April 2026.

mitigation for developers

If your web application connects via WebSocket to a local server (e.g. a companion native app or dev-mode tool), you have several options:

Use a local HTTPS server (with a self-signed cert or mkcert): Chrome may allow the connection with permission after the user trusts the cert.
Serve from localhost: Pages served from http://localhost are themselves treated as a local context and are subject to different rules than public pages.
Inform users: If the permission prompt is expected, explain it in your onboarding UI — users may dismiss an unexpected prompt and assume something is broken.
Switch to Isolated Web Apps (IWAs): IWAs have different network access rules and can use allow="loopback-network" in the manifest.