New permission prompt for Local Network Access  |  Blog  |  Chrome for Developers (original) (raw)

Published: June 9, 2025

Chrome is adding a new permission prompt for sites that make connections to a user's local network as part of thedraft Local Network Access specification. The aim is to protect users from cross-site request forgery (CSRF) attacks targeting routers and other devices on private networks, and to reduce the ability of sites to use these requests to fingerprint the user's local network.

To understand how this change impacts the web ecosystem, the Chrome team is looking for feedback from developers who build web applications that rely on making connections to a user's local network or to software running locally on the user's machine. From Chrome 138, you can opt-in to these new restrictions by going to chrome://flags/#local-network-access-check and setting the flag to "Enabled (Blocking)".

What is Local Network Access?

Local Network Accessrestricts the ability of websites to send requests to servers on a user's local network (including servers running locally on the user's machine), requiring the user grant the site permission before such requests can be made. The ability to request this permission is restricted to secure contexts.

A prompt with the text 'Look for and connect to any device on your local network.'

Example of Chrome's Local Network Access permission prompt.

Many other platforms, such asAndroid,iOS, andMacOShave a local network access permission. For example, you may have granted this permission to access the local network to the Google Home app when setting up new Google TV and Chromecast devices.

What kinds of requests are affected?

For the first milestone of Local Network Access, we consider a "local network request" to be any request from the public network to a local network or loopback destination.

A local network is any destination that resolves to the private address space defined in Section 3 of RFC1918 in IPv4 (e.g., 192.168.0.0/16), an IPv4-mapped IPv6 address where the mapped IPv4 address is itself private, or an IPv6 address outside the ::1/128, 2000::/3, and ff00::/8 subnets.

Loopback is any destination that resolves to the "loopback" space (127.0.0.0/8) defined in section 3.2.1.3 ofRFC1122 of IPv4, the "link-local" space (169.254.0.0/16) defined in RFC3927 of IPv4, the "Unique Local Address" prefix (fcc00::/7) defined in Section 3 ofRFC4193 of IPv6, or the "link-local" prefix (fe80::/10) defined in section 2.5.6 ofRFC4291 of IPv6.

A public network is any other destination.

Because the local network access permission is restricted to secure contexts, and it can be difficult to migrate local network devices to HTTPS, the permission-gated local network requests will now be exempted from mixed content checks if Chrome knows that the requests will be going to the local network before resolving the destination. Chrome knows a request is going to the local network if:

// Example 1: Private IP literal is exempt from mixed content.
fetch("http://192.168.0.1/ping");

// Example 2: `.local` domain is exempt from mixed content.
fetch("http://router.local/ping");

// Example 3: Public domain is not exempt from mixed content,
// even if it resolves to a local network address.
fetch("http://example.com/ping");

// Example 4: Adding the `targetAddressSpace` option flags that
// the request will go to the local network, and is thus exempt
// from mixed content.
fetch("http://example.com/ping", {
  targetAddressSpace: "local",
});

What's changing in Chrome

Chrome 138

Our initial version of Local Network Access is ready for opt-in testing in Chrome 138. Users can enable the new permission prompt by settingchrome://flags#local-network-access-check to "Enabled (Blocking)". This supports triggering the Local Network Access permission prompt for requests initiated using the JavaScript fetch() API, subresource loading, and subframe navigation.

A demo site is available athttps://local-network-access-testing.glitch.me/for triggering different forms of local network requests.

Known issues and limitations

Chrome 139 and beyond

Our intent is to ship Local Network Access as soon as possible. Recognizing that some sites may need additional time to be updated with Local Network Access annotations, we will add an Origin Trial to let sites temporarily opt-out of the secure contexts requirement before we ship Local Network Access by default. This should provide a clearer migration path for developers, especially if you rely on accessing local network resources over HTTP (as these requests would be blocked as mixed content if requested from an HTTPS page in browsers that don't yet support the Local Network Access mixed content exemption).

We will also be adding a Chrome enterprise policy for controlling which sites can and cannot make local network requests (pre-granting or pre-denying the permission to those sites). This will allow managed Chrome installations, such as those in corporate settings, to avoid showing the warning for known intended use cases, or to further lock down and prevent sites from being able to request the permission at all.

We plan to continue integrating the Local Network Access permission with different features that can send requests to the local network. For example, we plan to ship Local Network Access for WebSockets, WebTransport, and WebRTC connections soon.

We will share more information as we get closer to being able to fully launch Local Network Access in Chrome.

Feedback wanted

Previous feedback on Private Network Access development was incredibly valuable in guiding us to our new Local Network Access permission approach. We would like to once again thank everyone who has been involved over years.

If you develop or are a user of a website that relies on making connections to the user's local network or software running locally on the user's machine, the Chrome team is interested in your feedback and use cases. There are two things you can do to help: