Chrome's Local Network Access (LNA) Permission Explained

You’re testing a web app that talks to a local API, a dev server running on port 3000, or a hardware device on your network. Chrome suddenly shows a dialog: “[Site] wants to look for and connect to any device on your local network.” You weren’t expecting it. Here’s exactly what’s happening and why.

What Is Chrome’s Local Network Access Permission?

Chrome’s Local Network Access (LNA) is a browser security change that prevents public websites from silently making requests to devices on your local network. Starting with Chrome 142, the browser gates these requests behind an explicit user permission prompt.

Before LNA, any website you visited could use your browser as a proxy to quietly probe your router, printer, local API, or any other device on your network — without you knowing. That’s a real attack vector. A malicious site could exploit it to perform cross-site request forgery (CSRF) against vulnerable local devices or fingerprint your network topology.

LNA closes that gap by requiring user consent first.

This replaces an earlier attempt called Private Network Access (PNA), which relied on server-side CORS preflights and required local devices to explicitly opt in. That approach stalled because updating firmware on millions of routers and IoT devices is impractical. LNA shifts the responsibility to websites instead, which are far easier to update.

For more background, see the official Chrome security update on Local Network Access restrictions.

What Triggers the Chrome Local Network Access Permission Prompt?

The prompt appears when a page served from a public origin tries to reach a local or loopback destination. Chrome defines three address spaces:

Any request crossing from public → local or public → loopback triggers LNA. Common developer scenarios that hit this:

• A hosted web app calling http://192.168.1.1/api
• A cloud dashboard connecting to a locally running agent on localhost:8080
• A device setup page (served from a manufacturer’s public site) communicating with hardware on your LAN
• A ZTNA or VPN solution routing traffic through IPv6 ranges Chrome classifies as local (like fc00::/7)

Key Constraints Developers Need to Know

Secure contexts only. The LNA permission can only be requested from HTTPS pages. However, since local devices often can’t serve HTTPS, Chrome may relax mixed-content restrictions for clearly local targets after permission is granted, since many devices only expose HTTP endpoints.

// Chrome knows this is local — mixed content check exempted
fetch("http://192.168.0.1/ping");

// Chrome knows this is local via annotation
fetch("http://mydevice.example.com/ping", { targetAddressSpace: "local" });

// Chrome does NOT know this is local until DNS resolves — not exempted
fetch("http://example.com/ping");

Workers need special handling. Service Workers and Shared Workers require the parent origin to have already been granted the LNA permission before they can make local network requests. There’s no way for a worker to trigger the prompt directly.

Iframes require delegation. Embedded frames need explicit permission delegation via Permissions Policy (local-network-access) to make local network requests.

WebTransport and WebRTC are not yet covered by LNA gating — support is expected in future Chrome releases. WebSocket connections to local addresses follow the same local network access restrictions as other network requests.

Why This Matters More Than It Looks

The Chrome local network security change aligns the browser with what iOS, Android, and macOS have done for years at the OS level. Apps on those platforms already ask for local network access. Chrome is catching up.

For developers accessing local devices from the browser — whether that’s a dev server, a hardware interface, or a local agent — the practical impact is clear: your app now needs to trigger the permission prompt intentionally, handle the case where a user denies it, and ensure requests originate from a secure context.

Conclusion

Chrome’s Local Network Access permission is a meaningful shift in how browsers handle the boundary between the public web and your private network. For end users, it closes a long-standing blind spot. For developers, it introduces a new requirement: any public-origin page that reaches into local address space must now account for an explicit permission gate.

The adjustment is straightforward. Serve your pages over HTTPS, anticipate permission denials in your UI, delegate access to iframes via Permissions Policy, and test early. Use chrome://flags/#local-network-access-check set to “Enabled (Blocking)” to see exactly what Chrome 142 users will experience. The sooner you adapt, the fewer surprises your users will face.

FAQs

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.