DNS Rebinding: How a Website Can Attack Your Local Network

Many people assume that a device “hidden” in the local network - a router, an IP camera, a printer, an administration panel without exposure to the Internet - is safe because “no one from outside can reach it”. DNS rebinding disproves this assumption: it allows a malicious website, opened in the victim’s browser, to send requests to devices on its local network and read the responses. It’s an attack as old as the web itself, but it’s still surprisingly effective because it bypasses one of the browser’s fundamental security features.

Foundation: same-origin policy

Browsers are protected by a same-origin policy (SOP). In short: a script from https://atakujacy.example can send a request to http://192.168.1.1, but it will not read the response because it is a different origin (different host). This prevents a website from simply “reading” your router.

The key point, however, is that the origin is defined by the hostname, not the IP address. And this is the vulnerability that DNS rebinding exploits.

Step-by-step attack mechanism

The attacker controls a domain, say attacker.example, and its DNS server. Crucially, the domain has a very short TTL - for example, only a few seconds.

1. The victim visits attacker.example through a phishing link, advertisement or another lure. DNS returns the real address of the attacker’s server, and the browser loads malicious JavaScript.
2. The script repeatedly queries attacker.example. To the browser, it remains the same origin and hostname.
3. The attacker “rebinds” DNS. Because the TTL was short, the browser soon resolves attacker.example again. This time, the attacker’s DNS server returns an address from the victim’s local network, such as 192.168.1.1 for a router or 127.0.0.1 for a localhost service.
4. The script reaches the LAN device and can read its responses. From the browser’s perspective, the origin is still attacker.example, so the same-origin policy may not block the read. The script communicates with the local device as though it were the original site.

Effect: the website talks to your router, camera, admin panel or development service on the localhost - and sends the obtained data back to the attacker. The goals can be serious: changing router settings, stealing data from an unsecured API, and in the cloud - reaching the instance metadata endpoint (source of credentials).

Why it still works

DNS rebinding is in full swing because it is based on three common false assumptions:

• “Since it’s only on the LAN, there’s no need for authentication.” Many devices and administration panels on the local network do not require logging in or have default passwords. DNS rebinding turns “only available locally” into “available to any website you open”.
• “We do not validate the Host header.” Many local services respond regardless of the hostname supplied in the request, so they accept attacker.example when it resolves to their IP address.
• “It’s too exotic.” And this is a ready-made, automated technique that can be trivially incorporated into a malicious website.

Defense: network layer and service layer

Effective protection combines two levels - because neither is enough on its own.

On the network/resolver side (block rebinding):

• Protection against DNS rebinding in the resolver. Many resolvers (e.g. dnsmasq with the stop-dns-rebind option, Pi-hole, router resolvers) can reject DNS responses from public domains pointing to private addresses (RFC 1918: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and feedback loop. This deprives the attack of a key step - “switching” to the local address.

Service side (don’t trust that you are only on LAN):- Verify Host header. The local service should only respond to expected names (localhost, its actual address) and reject requests with foreign Host - a simple, effective barrier.

• Require authentication and tokens. Even the “internal” panel must require login; lack of authentication is the main reason why rebinding is profitable. Follows the Zero Trust approach: local network is not a trust boundary.
• Loopback services when possible and use HTTPS with certificate validation - a mismatched certificate makes the attack more difficult.
• Use browser mechanisms. Modern browsers implement Private Network Access (formerly CORS-RFC1918): requests from a public site to a private network require additional permission. This is an important layer, but it does not replace securing services.

Note for application developers: lack of validation Host and “trusting the local network” are the same family of errors as bad access control in OWASP Top 10 and loose CORS described in the header guide.

Summary

DNS rebinding shows that “only available on the local network” does not mean “secure”. The attack bypasses the same-origin policy by replacing the address with the same hostname, and turns any open page into a bridgehead to your router, IoT devices, and internal services. Defense requires two layers: blocking rebinding on the resolver (rejecting private IPs in public domain responses) and hard security of the services themselves (Host validation, authentication, lack of trust in “being on the LAN”).

If you are building devices, admin panels or internal services and want to test their resistance to DNS rebinding and related attacks, contact us - application and infrastructure security tests cover this scenario.

Frequently asked questions (FAQ)

Does HTTPS protect against DNS rebinding? Partially. If the local service requires a valid HTTPS certificate for its hostname, the attack is harder because the certificate will not match attacker.example. However, many LAN devices use plain HTTP or a self-signed certificate, so validated HTTPS is one layer rather than a complete solution.

Will a regular firewall stop this attack? No. The requests come from the victim’s browser, which is inside the network, so the edge firewall sees normal local traffic. Therefore, the defense must work on the DNS resolver and the services themselves, not on the edge firewall.

I’m in the cloud - does this apply to me? Yes, and it can be particularly dangerous. DNS rebinding can be used to reach the instance metadata endpoint (e.g. 169.254.169.254), which is sometimes a source of temporary credentials. Therefore, blocking access to metadata and forcing its newer, secured versions is an important element of cloud hardening.

How do I check if my devices are vulnerable? The easiest way is to test: whether the service responds to requests with a foreign Host header, whether it requires authentication and whether the network resolver blocks private addresses in public domain responses. We take this scenario into account when testing the security of devices and internal applications.