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

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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 ↗