In 2018 a researcher named Brannon Dorsey pointed a web page at his own home network and found he could talk to his Google Home, his Chromecast, his Roku, and his Sonos speakers — not from some hacker’s laptop on the same Wi-Fi, but from a tab open in a browser, served by a domain on the public internet. The Google Home spoke through an undocumented REST API on port 8008. The Roku answered its External Control Protocol on port 8060 (that one got a CVE: CVE-2018-11314). Google, Roku, and Sonos all shipped patches.
The technique he used was not new. It was old enough to vote.
The same-origin policy trusts a name, not a place
Everything your browser does about security between sites rests on one rule: the same-origin policy. A script loaded from https://evil.example can talk to https://evil.example and nothing else. The “origin” is the triple of scheme, host, and port. Two pages share an origin only if all three match.
Look closely at the middle term. The origin is keyed on the host — the name. Not the IP address it resolves to. The browser decides whether two requests belong together by comparing strings like evil.example, never by comparing the machines those strings point at.
That seems fine, because normally a name maps to a stable address. But the mapping isn’t owned by the browser. It’s owned by DNS. And DNS is controlled by whoever runs the domain — which, when you’re visiting an attacker’s site, is the attacker.
That’s the whole bug. The browser enforces a boundary defined by a name, and the attacker controls what that name means.
How the rebind works
You visit evil.example. Their nameserver answers with the attacker’s real public IP and a deliberately tiny TTL — a few seconds. Your browser loads the page, JavaScript starts running, the origin is evil.example, all normal.
Then the script waits for the TTL to lapse and makes another request to the same origin. The browser, seeing the cached record expired, asks DNS again. This time the attacker’s nameserver answers with 192.168.1.1. Or 127.0.0.1. Or whatever address sits behind your firewall.
From the browser’s point of view nothing changed: still evil.example, still same origin, same-origin policy satisfied. From the network’s point of view everything changed: the request now goes to your router’s admin panel, or the unauthenticated API on the smart speaker in your kitchen. The script is talking to your internal network with your browser as the proxy, and the same-origin policy waved it through because the name never moved.
The Stanford paper that named and dissected this in 2007 — “Protecting Browsers from DNS Rebinding Attacks,” by Collin Jackson, Adam Barth, Andrew Bortz, Weidong Shao, and Dan Boneh — put a price tag on it. They estimated an attacker could temporarily hijack roughly 100,000 browsers, turning each into an open proxy onto its own network, for under $100 in ad buys. The browser is the foothold; you rent the eyeballs.
Why the obvious fix isn’t enough
The obvious defense is to stop honoring the rebind: cache the first answer and ignore the short TTL. Browsers do this. It’s called DNS pinning — once a hostname resolves to an IP, the browser pins it for a while regardless of what the TTL says.
Pinning helps and it does not solve the problem. The attacker just waits the pin out — pages can sit idle and retry. Or they serve two A records at once, point one at a host they then take offline, and let the browser fail over to the second (internal) address mid-session. Researchers at Intruder demonstrated split-second rebinding in Chrome and Safari that collapses the window from minutes to under a second by abusing exactly this multi-answer behavior. Every layer that tries to fix rebinding by guessing the attacker’s timing loses to an attacker who picks the timing.
The other family of defenses works at the resolver, not the browser. You teach DNS to refuse answers that point inward. dnsmasq has had --stop-dns-rebind for years; it rejects upstream replies containing RFC 1918 ranges, 127.0.0.0/8, and 0.0.0.0/8. The catch is the same one that dooms most good defaults: it isn’t on by default. Most home routers ship dnsmasq with the flag off, and most people running a resolver never flip it.
And the filtering is only as complete as its list. Last year’s “0.0.0.0 day” was the reminder: browsers had learned to block responses pointing at 127.0.0.1, but on Linux and macOS 0.0.0.0 also resolves to localhost, and nobody had blocked that. A year-plus of patched localhost protection, undone by a second address for the same machine.
The real lesson is about your LAN, not your browser
You can read DNS rebinding as a browser bug — a long-running gap in the same-origin policy that vendors keep papering over. Chrome’s Private Network Access work is the latest paper: it makes a page on the public internet send a CORS-style preflight before it’s allowed to reach a private address, and the device has to opt in. It’s a genuine improvement. It is also playing defense on the wrong field.
The uncomfortable part is what rebinding reveals about everything behind the browser. Your router’s admin page, the printer’s config server, the smart speaker’s control API, the database bound to localhost “because it’s only local” — every one of those decided it was safe to skip authentication because of where the request came from. Inside the network equals trusted. DNS rebinding exists precisely because that assumption is false: an attacker on the public internet can borrow an inside position any time you open a tab.
We have a name for the principle that’s supposed to replace network-location trust, and the industry has worn it out in marketing decks. But strip the buzzword away and rebinding is the cleanest possible demonstration of why it’s right. The network is not a perimeter. “It’s only reachable from the LAN” is not access control. The fix that actually holds isn’t a smarter TTL heuristic or a longer blocklist of inward-pointing addresses — it’s that the thing on your LAN should have asked who was calling before it did what it was told.
Every device that assumed the local network was a wall has been wrong for over twenty years. The browser just keeps proving it.