Firefox 153 puts a permission prompt between the web and your LAN

For as long as the web has existed, a page loaded from anywhere on the internet could quietly fire requests at 192.168.0.1 — your router, your printer, your NAS — and the browser would oblige. Firefox 153.0, released on 21 July 2026, closes that door. The release notes state it in one line: "Local Network Access restrictions are now enabled by default for all users."

The threat this closes

Mozilla's security documentation on MDN is explicit about what the feature defends against. Local Network Access "places restrictions on the ability of websites to make requests to the user's local network, mitigating the risk of attacks such as cross-site request forgeries," because attackers "can use such requests to initiate certain classes of cross-site request forgery (CSRF) attacks against local network devices such as routers and printers."

A common attack typically involves an attacker's site attempting to access a user's router and change their DNS settings.

MDN, "Local network access"

Three address spaces, two permissions

MDN's model divides the network into three address spaces: public, local ("only accessible on the local network; its target will differ on different networks. For example, 192.168.0.1"), and loopback ("only accessible on the local device … generally known as localhost"). Reaching from a more public space into a more private one now needs an explicit grant: "Loopback and local requests are gated behind specific permissions — local-network and loopback-network, respectively," and the user is shown a permission dialog when a site first tries.

The gate covers far more than fetch(): subresource loads, subframe navigations, Service Workers, WebSockets, WebTransport and WebRTC are all listed as affected. A site can check where it stands:

navigator.permissions.query({ name: "local-network" }).then((result) => {
  if (result !== "granted") {
    adviseUserOnRemediation();
  }
});

The error shape: no HTTPS, no prompt

The detail that will bite self-hosters first: "The permissions are restricted to secure contexts. On non-secure contexts, all requests will fail." A dashboard served over plain HTTP that calls out to devices on the LAN does not get a permission prompt — its cross-space requests simply fail. If an internal tool broke in Firefox this month, look here first: the page has to be served over HTTPS before the prompt can appear at all, and then the permission has to be granted.

The escape hatch is a policy

For managed fleets there is a LocalNetworkAccess enterprise policy — listed with compatibility "Firefox 150", so the machinery predates this release's default flip. Its options: Enabled (enforce the checks, default true), BlockTrackers (block third-party trackers from reaching localhost and the local network), EnablePrompting, SkipDomains (trusted domains exempt from the checks, with wildcard support such as *.company.com), and Locked to stop users changing any of it.

Also in 153: extensions lose file://

The same philosophy shows up on a second front in this release. Per MDN's developer notes, "Extensions now require explicit user permission to access file:// URLs," via "a separate 'Access local files on your computer' option in the extension's permissions settings (desktop only), and file access is turned off by default for all extensions, including existing ones." Ambient reach — into the LAN, into the filesystem — is becoming something a user grants, not something the platform assumes.

Primary sources: Firefox 153.0 release notes, Local network access — MDN, Firefox 153 for developers — MDN, LocalNetworkAccess policy — Firefox admin docs, read 2026-07-31.