Local Network Access restrictions on Service Worker WindowClient.navigate()

at a glance

why it exists

Chrome's Local Network Access protections prevent public websites from silently reaching devices on the user's private network. Earlier work applied LNA checks to fetch() requests initiated from service workers. However, service workers can also trigger subframe navigations via WindowClient.navigate() — and that path was not covered. A compromised or malicious service worker from a public origin could navigate an embedded subframe to a local admin interface or device URL without the user's knowledge. Chrome 147 closes this hole by applying the same initiator-based LNA logic to WindowClient.navigate() calls.

Only subframe WindowClient navigations are affected. Chrome does not currently enforce LNA restrictions on main-frame navigations.

what changes

When a service worker calls windowClient.navigate(url):

• If the WindowClient is a main frame: no change, no LNA check is applied.
• If the WindowClient is a subframe and the target URL resolves to a local/private address:
  • Chrome uses the WindowClient (i.e. the subframe's origin) as the navigation initiator.
  • If the initiator is a public origin, the LNA permission check is triggered.
  • If the user has not granted permission, or the context is not secure, the navigation is blocked.

Affected address ranges

browser support

see also

• WICG Local Network Access specification
• chromestatus — Local Network Access restrictions on Service Worker WindowClient.navigate() (5172375182245888)
• Local network access restrictions for WebSockets — Chrome 147