Browser Local Network Access (LNA) Permission Guide

For most of the web's history any page a user opened could send requests to the user's router, printer, NAS or a service listening on localhost, and many of those devices trusted anything that arrived from the inside. Local Network Access (LNA) changes that in Chromium-based browsers: a public website now needs the user's permission before it can reach the local network or loopback addresses. This guide explains what the permission covers, how it replaced the earlier Private Network Access preflight design, what breaks when it is enforced, and how to manage it with Chrome and Edge enterprise policies. It is written for browser and endpoint administrators, web developers whose sites talk to local devices or companion apps, and security teams who own device and localhost attack surface.

Key takeaways

The browser now gates public-to-private requests. Requests from a less private address space to a more private one (public to local, public or local to loopback) need a permission, granted by the user or by policy.
There are two permissions, not one. Chrome split the original local-network-access permission into local-network and loopback-network, with the old name kept as an alias.
CORS was never the protection. Simple requests reach the device without a preflight, which is why router CSRF and drive-by pharming worked; LNA closes that path before the request is sent.
Enterprise policy decides, not users. LocalNetworkAccessAllowedForUrls and the newer local and loopback allow and block lists let administrators pre-approve the few sites that need access and keep users from clicking Allow everywhere.
The opt-out is temporary. Edge documents LocalNetworkAccessRestrictionsTemporaryOptOut as removed after version 163; treat it as a migration crutch with an end date.

The problem LNA addresses

A browser sits on two networks at once: the public internet, where the page came from, and the user's own network, where routers, printers, cameras, development servers and desktop agents listen. The same-origin policy stops a page reading responses from another origin, but it never stopped the page sending the request. The WICG Local Network Access specification describes the result: public websites making requests to local devices enable cross-site request forgery style attacks such as drive-by pharming and SOHO pharming against routers, and CORS does not prevent them because CORS-safelisted methods and headers trigger no preflight. It also notes that software running web interfaces on a loopback address often assumes protections that do not exist.

Router and device takeover: a hidden form or image request to 192.168.1.1 that changes DNS settings, using default or no credentials. See the Securing Your Home Router Guide.
Localhost companion apps: desktop agents, developer tools, MCP bridges and device helpers that expose an HTTP or WebSocket API on 127.0.0.1 and treat "came from localhost" as authentication. See the Local MCP Server Security Guide.
Internal reconnaissance: timing and error differences let a page infer which internal hosts and ports respond, the browser-side equivalent of network service discovery (ATT&CK T1046).
Printers and IoT panels: embedded web servers with weak authentication and no CSRF protection. See the Printer and Print Server Security Guide.

The background on why the browser allowed this is in the Same-Origin Policy and Browser Security Model Guide and the CSRF Prevention Guide.

Address spaces: what counts as local and loopback

LNA classifies every IP address into one of three address spaces and checks requests that move towards a more private one. The specification is a W3C Community Group Draft Report (the version checked in November 2026 was dated 7 August 2026), not a W3C Recommendation, so details can change.

Address space	Meaning in the spec	Ranges (spec draft)	Permission needed to reach it
loopback	Target differs for every device	127.0.0.0/8, ::1/128, 0.0.0.0/32, ::/128, 198.18.0.0/15; localhost	loopback-network (from public or local origins)
local	Target differs based on network position	10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 100.64.0.0/10, 169.254.0.0/16, fc00::/7, fe80::/10 and others; .local mDNS names	local-network (from public origins)
public	Target the same for all devices globally	Everything else	None

IPv4-mapped IPv6 addresses (::ffff:0:0/96) are classified by the embedded IPv4 address, which closes an obvious bypass. Because classification is based on the IP address the request actually connects to, a public hostname that resolves to a private address is still treated as a request to the private space. Chrome's developer guide says that after DNS resolution the browser checks the address against any declared target space and aborts the request with a TypeError on a mismatch. The specification allows administrators to override the classification of specific address blocks, which matters for organisations that use the 100.64.0.0/10 shared address range or public IP space internally.

From Private Network Access to Local Network Access

LNA is the second attempt. The earlier design, Private Network Access (PNA), would have required the target device to opt in by answering a CORS preflight with an Access-Control-Allow-Private-Network header. Chrome's October 2024 update said PNA had shipped two parts, restricting private network requests to secure contexts and blocking insecure contexts from reaching 0.0.0.0/8, but that preflight enforcement, previously planned for Chrome 130, was on hold because of compatibility problems. The practical obstacle was that millions of deployed devices would never receive firmware that answers the preflight.

Aspect	Private Network Access (preflight design)	Local Network Access (permission design)
Who decides	The target device, by answering a preflight	The user, or an administrator through policy
Change needed on devices	New firmware sending the opt-in header	None required
Change needed on sites	Serve over HTTPS	Serve over HTTPS, request permission from a user gesture, declare targetAddressSpace
Status	Preflight enforcement on hold since October 2024	Prompt launched in Chrome 142; split permissions targeted at Chrome 145
Legacy header	Access-Control-Allow-Private-Network: true	Not needed; existing headers can stay

Chrome's announcement, published June 2025 and updated September 2025, made the opt-in test available from Chrome 138 through chrome://flags#local-network-access-check and said the permission prompt was launching in Chrome 142. The first milestone covered fetch(), subresource loads and subframe navigation from public to local or loopback destinations. The later blink-dev Intent to Ship split the single permission into local-network and loopback-network for Chrome 145 on desktop and Android, keeping local-network-access as an alias for permissions queries and Permissions Policy. Microsoft Edge follows Chromium and documents the same policies.

What is gated and how sites adapt

Chrome's current developer guidance lists the request types and the developer obligations:

fetch() and Request: gated; declare targetAddressSpace: "local" or "loopback". This also exempts an http:// target from mixed content blocking, which otherwise stops an HTTPS page calling an HTTP device.
WebSocket: gated when the URL is an IP literal, localhost or a .local name; for custom DNS names Chrome recommends wss://.
WebTransport: requires https:// and gates the connection behind the prompt; self-signed local certificates can be pinned with serverCertificateHashes.
Cross-origin iframes: both permissions have a default allowlist of 'self', so an embedded widget needs allow="local-network; loopback-network" on the iframe and a matching Permissions-Policy header on the top-level document.
Insecure pages: the permissions are denied automatically in top-level http:// contexts, so a site that needs local access must be served over HTTPS. See the Chrome HTTPS by Default guide.
Permission UX: query with navigator.permissions.query, request from a user gesture rather than on page load, and do not query the legacy local-network-access name, which Chrome's guide warns can crash the renderer in older versions.

Chrome's guide gives developers a test switch, --ip-address-space-overrides, to make a local test server appear public, and says new code should not rely on PNA preflight headers. WebRTC is handled separately; Microsoft's eCDN guidance pairs LNA policy with the WebRtcLocalIpsAllowedUrls policy. See the WebRTC Security Guide.

Managing LNA with enterprise policy

Left to users, the prompt becomes another dialog people click through. In managed fleets, decide centrally which sites may reach local and loopback addresses. The policy names below are documented by Microsoft for Edge; the same names apply to Chrome under HKLM\SOFTWARE\Policies\Google\Chrome.

Policy	Effect	Notes from the documentation
LocalNetworkAccessAllowedForUrls	Origins matching these URL patterns are exempt from LNA checks	Edge 140 and later on Windows and macOS; patterns such as https://app.example.com or [*.]example.com
LocalNetworkAccessBlockedForUrls	Blocks matching origins	Takes precedence over the allow list
LocalNetworkAllowedForUrls / LocalNetworkBlockedForUrls	Granular control of the local-network permission	Evaluated first in Microsoft's documented precedence order
LoopbackNetworkAllowedForUrls / LoopbackNetworkBlockedForUrls	Granular control of the loopback-network permission	Evaluated after the local policies
LocalNetworkAccessRestrictionsTemporaryOptOut	Failures only produce DevTools warnings	Edge 143 and later; documented as removed after Edge 163

Microsoft documents the precedence when an origin matches several lists: LocalNetworkBlockedForUrls, LocalNetworkAllowedForUrls, LoopbackNetworkBlockedForUrls, LoopbackNetworkAllowedForUrls, LocalNetworkAccessBlockedForUrls, then LocalNetworkAccessAllowedForUrls. Its Teams eCDN guidance is a real example of a vendor needing an allow entry: it lists the eCDN and Teams origins to add to LocalNetworkAccessAllowedForUrls so peer delivery keeps working. Check your browser version and the current policy list before deploying, because the granular policies are newer than the combined ones.

Decision guidance

Allow a site by policy when: it is a business application that must talk to a device or local agent (print management, eCDN, device enrolment portals, a ZTNA or endpoint agent's local listener), you own or contract the site, and it is served over HTTPS.
Prefer the granular policies: a site that needs the local network rarely needs loopback, and vice versa. Grant only the space required.
Block explicitly when: users can otherwise grant the permission and you have sites (ad-heavy portals, user-generated content hosts) where a grant would be dangerous.
Use the temporary opt-out only: to unblock a broken critical workflow while the vendor fixes it, scoped to the affected user group, with a removal date well before version 163.
Small organisations: leave the default prompt in place and add allow entries only when a tool breaks. Large organisations: inventory local and loopback dependencies first, then manage allow lists through the same change process as other browser policy. See the Browser Security Hardening Guide.

How to implement

Find dependencies: ask application owners which web apps talk to printers, scanners, cameras, eCDN peers or desktop agents; check vendor notices, since many ZTNA, endpoint and conferencing vendors have published LNA guidance.
Pilot on a ring: run a pilot group on a current browser with no opt-out, collect DevTools console errors and help desk tickets, and record each site that needs access and which space (local or loopback).
Write the allow lists: add HTTPS origins only, use exact origins rather than wildcards where possible, and keep local and loopback grants separate.
Roll out by ring: deploy the allow and block policies to pilot, then early adopters, then everyone, checking chrome://policy or edge://policy on sample machines.
Roll back safely: if a critical flow breaks, add a targeted allow entry first; use LocalNetworkAccessRestrictionsTemporaryOptOut only for the affected group and track its removal.
Fix the devices too: LNA is a browser-side control. Devices still need authentication, CSRF protection and current firmware, because other clients and compromised internal hosts are not subject to it.

Detection and measurement

Policy state: report the effective LNA policies from your browser management console or chrome://policy exports, and alert on the opt-out policy appearing outside its approved group.
Grants by users: where your browser management or enterprise browser tooling exposes site permissions, review which origins users have granted local or loopback access.
Localhost listeners: inventory processes listening on loopback ports on endpoints (EDR or osquery listening_ports), since each one is a target LNA now protects but did not before.
Device logs: configuration changes on routers and printers that originate from user workstations' browsers are worth alerting on.

Metrics that show the control is working:

Number of origins on allow lists, and the share with a named owner and review date.
Number of devices with the temporary opt-out enabled, trending to zero.
Help desk tickets attributed to LNA per month after rollout.
Number of loopback listeners on standard endpoints that accept unauthenticated HTTP requests.
Percentage of browsers on a version that enforces LNA.

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev. 5	AC-4 Information Flow Enforcement; SC-7 Boundary Protection	The browser enforces a flow boundary between public content and internal addresses
NIST SP 800-53 Rev. 5	CM-7 Least Functionality; SC-18 Mobile Code	Restrict what downloaded web code may do
NIST CSF 2.0	PR.PS-01	Browser configuration managed as a baseline
CIS Controls v8.1	Control 9 Email and Web Browser Protections	Managed browser configuration and restrictions
MITRE ATT&CK	T1189 Drive-by Compromise; T1046 Network Service Discovery; T1018 Remote System Discovery	Techniques that public-to-local requests enable

Common failure patterns

Turning on the opt-out fleet-wide: it removes the protection for every site to fix one application, and it will stop working after Edge 163 anyway.
Wildcard allow entries: allowing [*.]vendor.com or * grants every page on a large domain, including user content, the ability to reach internal devices.
Treating LNA as device security: it protects users browsing, not devices. Unauthenticated admin panels remain exposed to anything else on the network.
Localhost APIs without authentication: developers who relied on "only local code can reach 127.0.0.1" still need tokens and Origin checks, because a user can grant the permission and other local software is not gated.
Serving the integration page over HTTP: insecure top-level pages are denied the permissions automatically, so the integration fails in ways that look like network faults.

Practitioner checklist

Confirm which browser versions in the fleet enforce LNA and which permission names they use.
Inventory web apps that need local or loopback access, with an owner for each.
Grant access by policy to exact HTTPS origins, using local and loopback policies separately.
Block high-risk origins explicitly where users could otherwise grant access.
Limit LocalNetworkAccessRestrictionsTemporaryOptOut to named groups with a removal date.
Require authentication and Origin checks on every localhost and device web interface you build.
Monitor policy drift, user grants and loopback listeners on endpoints.
Re-check the specification and Chrome guidance each quarter while the design is still a draft.

Browser Local Network Access Guide: The Permission That Stops Websites Reaching Routers, Printers and Localhost