v147 · Security · Local Network Access
Local Network Access restrictions for WebSockets
Chrome 147 extends Local Network Access (LNA) protections to WebSocket connections. Public websites can no longer open WebSocket connections to local network or loopback hosts without the server sending a preflight response granting access.
concepts
-
WebSockets Demo
Shows how a WebSocket connection attempt from a public page to a local network host behaves in Chrome 147 — the browser now sends a preflight before upgrading to WebSocket protocol.
-
Preflight Flow
Explains the LNA preflight handshake for WebSockets: the HTTP upgrade request headers Chrome sends, the server response headers required to grant access, and what happens when the server doesn't respond correctly.
-
WebSocket LNA Upgrade Flow
Step-by-step HTTP upgrade handshake visualiser — switch between "server allows LNA", "server blocks LNA", and "pre-Chrome 147" to see the exact headers at each stage, plus a URL checker that classifies any WebSocket target as requiring an LNA preflight or not.
-
WebSocket Security Audit
Paste JavaScript code and get an automated audit of every
new WebSocket(url)call — classifying each URL as safe, warning, or blocked based on scheme and network tier. Generates server fix snippets in Node.js, Go, or Python implementing the required OPTIONS preflight handler for LNA compliance. -
Compatibility Lab
Detects WebSocket API availability, classifies page origin context (public / private / loopback), and probes whether LNA enforcement applies to WebSocket connections from this page. Provides the server-side WebSocket upgrade preflight pattern and the connection error detection strategy.
why it shipped
Before Local Network Access restrictions, a malicious website could open a WebSocket connection to devices on a visitor's home or corporate network — routers, printers, smart home devices, internal APIs — simply by connecting to a local IP address. The target device would accept the connection without any indication it came from a public web page. Chrome 147 closes this attack vector: WebSocket connections from public contexts to local network addresses now require the server to explicitly opt in via a preflight response, matching the protection already applied to HTTP Fetch requests.
the change
// A public website trying to connect to a local WebSocket server:
const ws = new WebSocket('ws://192.168.1.100:8080/ws');
// Chrome 147: before the WebSocket upgrade, Chrome sends an
// HTTP preflight with:
// Access-Control-Request-Private-Network: true
//
// The local server must respond:
// HTTP/1.1 200 OK
// Access-Control-Allow-Private-Network: true
//
// If the server doesn't respond correctly:
// → WebSocket connection fails with a network error
// → ws.onerror fires; ws.readyState = CLOSED
ws.onerror = () => {
// Check if local server has LNA headers before retrying
};
// No change for:
// - WebSocket connections from local/private to local/private
// - WebSocket connections from public to public origins
// - Localhost connections from localhost
references
implementation reference
Need the exact API surface, compatibility boundaries, errors, lifecycle, and source links? Read the matching gendn reference ↗