A public web page can quietly probe 127.0.0.1 and your router, timing the replies to map what's running on your network. Here's what stops it now.
An ordinary tab, open to an ordinary public website, can ask your browser to make requests to 127.0.0.1 and to your router's LAN address — say 192.168.1.1 — and time how long each one takes to answer. It never needs to read the response body; cross-origin rules already block that. It just needs to know whether something answered fast, answered slow, or didn't answer at all. That's enough to build a map of what's running on the network behind your one public IP address, and until very recently, nothing in the browser stopped a page from doing it.
Key Takeaways
- A public web page can send requests to
localhostand to private LAN addresses like192.168.x.xfrom ordinary JavaScript —fetch(), an<img>tag, or a WebSocket connection all work, and none of them require special permissions by default. - The page doesn't need to read the response. Timing (did it answer, and how fast) and connection outcome (open vs. refused vs. timed out) are enough to tell whether something is listening on a given local address and port.
- What that leaks is about your machine and network, not your browser: a dev server on port 3000, a media server, a vendor's desktop agent, or a specific router model — facts that are stable, hard to change, and identifying in a different way than a canvas or font fingerprint.
- The same request shape is also a CSRF vector against routers and local admin panels that were never built to expect requests from a random public page.
- Chrome's fix, Local Network Access, is a user-facing permission prompt that launched in Chrome 142 — it replaced an earlier, quieter attempt called Private Network Access that asked the local device for consent instead of the user.
What a page can actually do
Nothing about this requires exotic browser APIs. A page that wants to probe your network can fire off a batch of ordinary requests — a fetch() call to http://127.0.0.1:3000/, an image element pointed at http://192.168.1.1/, or opening a WebSocket connection to ws://127.0.0.1:8080 — and watch what happens next. The same-origin policy stops the page from reading response contents, but it can't hide whether a fetch() promise resolved or rejected, how long an image element took to fire its load or error event, or whether a WebSocket reached onopen versus onerror. Time a batch of these across a range of common ports on 127.0.0.1 and the private address ranges (192.168.0.0/16, 10.0.0.0/8), and the pattern of successes, refusals, and timeouts is itself the scan result — no response body ever needs to leave the local network.
What it leaks: a fact about your machine, not your browser
Most of what BrowserInsight covers under fingerprinting — canvas output, installed fonts, WebGL renderer strings — describes your browser and its rendering stack. A local network scan describes something different: what software is actually running on the physical machine and the network segment it sits on. A response on port 3000 or 8080 often means a developer's local server. A device answering on your router's address in a way that matches a known admin-panel signature identifies the router model, sometimes down to firmware family. A response on the port a specific vendor's desktop sync agent or media server binds to identifies that software's presence on your LAN, whether or not it's running in the tab you're looking at. None of that comes from a header or a JavaScript API telling the page "the user has X installed" — it's inferred purely from which local doors answered a knock. That makes it a genuinely different signal from the fingerprinting entropy this site's fingerprinting guide usually discusses, and one with a different anonymity-set shape: it doesn't distinguish you from other visitors to the same page so much as it maps your specific home or office network.
The other half of the problem: CSRF against your router
Fingerprinting isn't the only reason this got fixed. The same request shape — a public page reaching into a private address it was never invited to — is also how cross-site request forgery attacks against routers and local admin panels work. A router's web interface, or a locally-bound admin panel for a NAS or IoT device, is often built with the tacit assumption that only someone already on the LAN can reach it. It has no reason to expect a request forged by JavaScript on a completely unrelated public site. Chrome names both halves of this post in a single sentence when it explains what the new permission is for: 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." Same request, two different things an attacker can do with it.
Mitigation history: preflight first, then a permission prompt
Chrome's first attempt at closing this gap was Private Network Access, and it's worth understanding why it didn't fully work before looking at what replaced it. PNA's headline idea was to gate requests from public pages to private-network targets behind a CORS preflight: before the real request went out, the browser would send an OPTIONS request asking the target device to explicitly opt in, by responding with an Access-Control-Allow-Private-Network: true header. In principle, that puts the decision in the hands of whoever controls the local device — a reasonable design. In practice, it never got out of the experimental phase. Chrome's preflight explainer records a rollback after problems surfaced in Chrome 98, then a return in Chrome 104 in a deliberately toothless form: a failed preflight only printed a warning in DevTools and the real request went through anyway, with the preflight's own timeout capped at 200 milliseconds so it couldn't stall page loads. Actual enforcement was penciled in for "Chrome 113 at the earliest," and explicitly conditioned on compatibility data showing the change was safe enough. It never shipped — Chrome's own Local Network Access announcement records the preflight approach being put on hold.
The neighbouring piece of PNA fared no better. Chrome's PNA update post tracks the other half of the effort — blocking private-network requests from insecure public pages — being deferred from Chrome 92 to Chrome 93, then to Chrome 94 after more developer feedback, with the deprecation trial that let affected sites keep working extended repeatedly (to 113, then 116) before finally running out in Chrome 117.
That's the core lesson PNA taught: asking the target device for consent doesn't work when most of the devices on real people's networks — routers, printers, smart-home hubs, network storage — will never receive a firmware update that teaches them to give it. No amount of deferring the deadline changes that, because the hardware isn't on the other end of the deadline.
Why a permission prompt beats a preflight here
Local Network Access — LNA — is Chrome's answer, and it moves the decision from the unreachable device to the person actually sitting at the keyboard. Instead of asking the router or dev server to opt in via a header it will never send, the browser now shows the user a prompt — Chrome's own copy for it reads "Look for and connect to any device on your local network" — the first time a public page tries to reach a private address. The user can allow it, once, if they trust the site (a smart-home dashboard genuinely needs this) or simply decline for the vast majority of pages that have no legitimate reason to be probing a home network at all. That flips the bottleneck: instead of waiting for millions of unmaintained devices to implement a new header, Chrome only needs the browser to enforce the check, and the person who owns the network makes the call every time.
The feature shipped in Chrome 142; from Chrome 138 onward you could switch it on yourself behind the chrome://flags#local-network-access-check flag. Chrome's definition of what it catches is narrower than "any request to a local address": a local network request is one from the public network to a local network or loopback destination. That covers RFC 1918 private ranges like 192.168.0.0/16, link-local addresses (169.254.0.0/16 and fe80::/10), IPv6 unique local addresses (fc00::/7), loopback (127.0.0.0/8 and ::1), and .local hostnames — precisely the address space a scanning script would sweep. What it does not yet cover is a page already served from a private address reaching further inward to loopback; Chrome has said it plans to extend the protection to all cross-origin requests bound for the local network later.
What a reader sees today
If you're on a recent Chrome and a site tries to reach an address on your LAN, you'll see the permission prompt rather than a silent request. Most sites you visit will never trigger it, because they have no reason to talk to your router or a local dev server — if one does, and you don't recognize why, declining is the safe default. This is a Chrome-led rollout, not a universal one yet: don't assume the same prompt or the same protection exists in every browser just because you've seen it in one. If you want to know what your current browser and network setup expose beyond this specific mechanism, BrowserInsight's fingerprint check covers the wider set of machine- and browser-level signals a page can read without any permission prompt at all.
Where this fits next to the site's other privacy topics
It's easy to lump this in with unrelated tracking techniques that happen to live on nearby pages here, so to be explicit about the boundary: CSS fingerprinting is a stylesheet inferring device traits like dark mode or pointer type — no network requests involved. Session replay is a script recording what you do inside a page you're already on. Browser extension privacy is about installed add-ons reading page data, not the browser itself acting as a network scanner. Persistent visitor IDs are about re-identifying you across visits, not mapping your LAN. This post is specifically about the browser being turned into a probe against the private network the machine sits on — a distinct mechanism from all four, even though they share the general theme of a page learning more about you than you volunteered.
Frequently Asked Questions
Does this affect every browser, or just Chrome?
Local Network Access is a Chromium feature that launched in Chrome 142. Coverage in other engines varies and changes over time, so check your specific browser's release notes rather than assuming the protection is universal — the underlying request techniques (fetch, <img>, WebSocket) work the same way in any browser until that browser specifically restricts them.
Can a site scan my network without me noticing anything?
Before Local Network Access, yes — a script probing dozens of local addresses and ports produces no visible UI at all; the only trace was in browser DevTools' network panel, which almost no one checks. That silence, more than the technical mechanism itself, is what made this worth fixing with a permission prompt rather than leaving it to site-by-site good faith.
Is this the same thing as WebRTC leaking my local IP address?
No, though both involve your local network. WebRTC's ICE candidate gathering can reveal your local IP address as a side effect of setting up a peer connection. This is different: a page actively sends requests to addresses on your network and reads the timing/outcome, rather than incidentally learning one address about your own machine.
Do I need to do anything to be protected?
If you're on a current version of Chrome, the permission prompt is on by default — there's no setting to enable. Just decline the prompt on sites that have no obvious reason to be talking to your local network, the same way you'd treat any permission request that doesn't match what the site claims to do.
Why did Private Network Access take so long to become Local Network Access?
Because its original design assumed local devices could be updated to answer a new kind of request, and most consumer routers, printers, and IoT devices are effectively never updated after they ship. Years of enforcement dates got pushed back before Chrome concluded the fix had to live entirely in the browser and the user's decision, not depend on cooperation from hardware that would never arrive.
Conclusion
A public web page reaching into 127.0.0.1 and your router's LAN address isn't a hypothetical — it's a request your browser would happily send, timed just carefully enough to map what's listening, without ever needing to read a byte of the response. Private Network Access tried to close that gap by asking unreachable local devices for permission and spent years finding out that doesn't scale. Local Network Access asks you instead, with a permission prompt that shipped in Chrome 142. The mechanism is worth knowing even if you never see the prompt yourself: it's one more example of a browser feature that looks unrelated to your identity — a raw network request — turning out to describe your machine and your network as precisely as any fingerprinting script.
Recommended Reading:
- Browser Fingerprinting Explained: How to Protect Your Privacy
- CSS Fingerprinting: Tracking Without JavaScript
- Session Replay Scripts: How Sites Record Your Every Move
- Persistent Visitor IDs: Surviving Incognito, VPNs & Cache Clears
- Browser Extension Privacy Risks: Your Add-ons May Be Watching You
- Browser Fingerprint Entropy and Anonymity Sets Explained
