What Is DNS Rebinding?

DNS rebinding is an attack that abuses the gap between DNS resolution and the browser’s same-origin policy to make a victim’s browser send requests to a private, internal, or otherwise off-limits address on behalf of a page controlled by the attacker. It works by changing what a domain name resolves to after the browser has already decided to trust it, turning a script running on an attacker’s public page into a proxy that reaches inside the victim’s private network.

Why the browser trusts a domain, not an IP

The same-origin policy restricts what a script can do based on origin — scheme, hostname, and port — not the IP address behind that hostname. A browser resolves evil.example.com to an IP address once, loads the page, and from then on treats requests back to evil.example.com as same-origin, without re-checking whether the IP that hostname points to has changed. DNS rebinding exploits exactly that assumption.

How the attack works, step by step

1. Short TTL setup. The attacker controls a domain and its DNS server, and sets a very short DNS time-to-live (TTL) — often 0 or a few seconds — on its records.
2. First resolution. The victim visits evil.example.com, which briefly resolves to a real, attacker-controlled public IP. The page loads normally and runs JavaScript.
3. Rebinding. Because the TTL is so short, the browser is willing to re-resolve the domain almost immediately. The attacker’s DNS server now returns a different address — commonly 127.0.0.1, a private RFC 1918 address like 192.168.1.1, or the address of an internal service the attacker is targeting.
4. Same-origin, new target. The already-loaded page’s script makes a request to evil.example.com again. The browser sees the same hostname it already trusted and applies the same-origin rules — but the request now physically goes to the new, internal IP address instead of the attacker’s public server.

The victim’s browser, sitting inside the private network (behind a firewall, on a corporate LAN, or simply on localhost), becomes the thing making the request — bypassing network-level access controls that assumed only trusted machines could reach that internal address in the first place.

What it’s used to attack

DNS rebinding is most commonly aimed at services that bind to localhost or a private IP and assume that’s proof a request is trustworthy — a pattern common in developer tools, IoT device admin panels, and background daemons that expose an HTTP API without authentication because “only local processes can reach it.” Historical examples include local development servers, home routers with unauthenticated admin interfaces, and smart-home hubs that expose configuration APIs on the local network. If any of those accept requests without checking the Host header or requiring authentication, a rebinding attack from a page the victim merely has open in a tab can read configuration, trigger actions, or exfiltrate data — all without ever compromising the victim’s machine directly.

It’s conceptually related to server-side request forgery, but the roles are reversed: SSRF tricks a server into making an unintended request, while DNS rebinding tricks a browser — and by extension whatever network that browser sits on — into doing the same thing from the client side.

Defenses

Validate the Host header on internal services. Any local or internal HTTP service should check that incoming requests present an expected Host value (like localhost or a specific internal hostname) and reject anything else. This single check defeats most rebinding attacks, since the attacker’s rebound request will carry the Host header of the attacker’s domain, not the internal one the service expects.

Require authentication even on “local-only” services. Binding to 127.0.0.1 is not an access control mechanism by itself — DNS rebinding proves that a browser on the same machine can still be tricked into reaching it. Sensitive local services should require a token or other credential regardless of what address they listen on.

DNS pinning and TTL enforcement. Some browsers and DNS resolvers pin a resolved address for a minimum duration regardless of the TTL a malicious DNS server requests, closing the window an attacker needs to rebind mid-session. This mitigates but doesn’t eliminate the risk, since it’s a defense in the resolver rather than the vulnerable service.

Reject private-range responses for public domains. DNS resolvers and firewalls that filter or reject DNS responses resolving a public-facing domain to a private (RFC 1918) or loopback address close off the most common rebinding target, since legitimate public domains have no reason to resolve to 127.0.0.1 or an internal LAN address.

Use a Content Security Policy. A strict CSP that limits which origins a page’s scripts are allowed to connect to reduces the blast radius of a page that does get rebound, though it doesn’t stop the DNS-level trick itself.

Why it still matters

DNS rebinding isn’t a new technique, but it resurfaces whenever a new class of local-network tool ships an unauthenticated HTTP API and assumes network position is a sufficient trust boundary — a recurring pattern with developer tooling, smart-home devices, and local AI or automation agents that expose a control API on localhost for convenience. The fix is always the same regardless of what’s being protected: never treat “the request came from localhost” or “the request came from the LAN” as proof of legitimacy on its own, because DNS rebinding shows exactly how a browser can be turned into a proxy for that request without the user’s knowledge.

The takeaway

DNS rebinding works because a browser’s same-origin trust is anchored to a hostname, while the IP address behind that hostname can change moments after the page loads. An attacker with control over a domain’s DNS records can flip that address from a public server to an internal one, turning the victim’s own browser into a bridge into their private network. The reliable fix isn’t network position — it’s making internal and local services check the Host header and require real authentication, the same way any public-facing service would.