DNS Rebinding Attack: How Browsers Are Tricked Into Bypassing Same-Origin Policy

A DNS rebinding attack exploits the gap between DNS resolution and the browser's same-origin policy. The attacker controls a domain that initially resolves to their own server, then switches the DNS response to point to an internal IP address (like 192.168.1.1). The browser, having already loaded the attacker's page, now treats requests to the internal IP as same-origin when the scheme, hostname, and port remain the same while the resolved IP changes. Browser network restrictions and rebinding defenses can still block the attempt; a low TTL alone does not guarantee it works.

This attack is uniquely dangerous because it turns the victim's own browser into a proxy for attacking internal network services that are not directly accessible from the internet.

How DNS Rebinding Works

The attack unfolds in several steps:

1. Setup. The attacker controls a domain (attacker.com) and its authoritative nameserver. They configure the domain with a very short TTL (typically 0 or 1 second).

2. Initial load. The victim visits attacker.com. The DNS response returns the attacker's server IP (e.g., 203.0.113.10). The browser loads a page containing JavaScript.

3. DNS rebind. The attacker's nameserver changes the DNS record for attacker.com to point to an internal IP address (e.g., 192.168.1.1, the victim's router).

4. Exploitation. The JavaScript on the loaded page makes a new request to attacker.com. The browser resolves the hostname again (because the TTL has expired) and gets the new IP: 192.168.1.1. The browser sends the request to the internal device.

5. Same-origin pass. Because the browser checks origin by hostname (not by IP), and the hostname is still attacker.com for both the page and the request, the same-origin policy is satisfied. The JavaScript can read the response.

Step 1: attacker.com → 203.0.113.10 (attacker's server)
        Browser loads malicious JavaScript

Step 2: attacker.com → 192.168.1.1 (victim's router)
        JavaScript makes request to attacker.com
        Browser resolves to 192.168.1.1
        Same-origin policy allows reading the response

The attacker now has JavaScript running in the victim's browser that can communicate with internal network devices as if it were a local application.

Why It Bypasses Firewalls

The attack is effective because:

• The initial connection is outbound. The victim's browser connects to the attacker's server through normal web browsing. No inbound firewall rules are violated.
• Internal requests come from the browser. The requests to 192.168.1.1 originate from the victim's own machine, inside the network perimeter.
• No exploits needed. The attack uses standard DNS behavior and standard browser behavior. There is no buffer overflow, no code injection, just a DNS record change.
• HTTPS is not a barrier. While HTTPS complicates the attack (because the internal service likely does not have a valid TLS certificate for attacker.com), many internal devices expose HTTP interfaces.

Real-World Targets

DNS rebinding is particularly effective against:

• Home routers: Most consumer routers have web-based administration panels at 192.168.1.1 with weak or default credentials. An attacker can use rebinding to change DNS settings, enable remote management, or modify firewall rules.
• IoT devices: Smart home devices, cameras, and thermostats often have HTTP APIs on the local network with no authentication.
• Development servers: Localhost services (databases, API servers, admin panels) running on 127.0.0.1 that developers assume are safe because they are not exposed to the internet.
• Cloud metadata services: AWS instance metadata at 169.254.169.254 can be accessed through rebinding to steal IAM credentials and other sensitive data.
• Internal web applications: Corporate intranets, admin panels, and monitoring dashboards that rely on network-level access control instead of authentication.

The Cloud Metadata Angle

AWS, GCP, and Azure all expose instance metadata services at well-known internal IP addresses. AWS uses 169.254.169.254. If a DNS rebinding attack targets a cloud instance, the attacker's JavaScript can query the metadata service and exfiltrate:

• IAM role credentials (temporary access keys)
• Instance identity documents
• User data scripts (which may contain secrets)
• Network configuration

This is why AWS introduced IMDSv2, which requires first obtaining a token via a PUT request, something a rebinding or SSRF payload generally cannot arrange. AWS describes it as defense in depth that blocks the vast majority of such paths, rather than as complete prevention, and it only helps if IMDSv1 is disabled rather than left available alongside it.

How Attackers Discover This Weakness

The attacker does not need to know the specific internal network layout. They can scan common internal IP ranges through the browser:

// The attacker's JavaScript probes common internal IPs
const targets = [
  '192.168.1.1',   // Common router
  '192.168.0.1',   // Common router
  '10.0.0.1',      // Common gateway
  '127.0.0.1:8080', // Development server
  '169.254.169.254' // Cloud metadata
];

For each target, the attacker creates a subdomain that rebinds to that IP. If the target responds, the attacker has found a live internal service.

How to Defend Against It

DNS-Level Defenses

DNS rebinding protection on your resolver:

Many modern DNS resolvers (like dnsmasq, Pi-hole, and Unbound) can be configured to reject DNS responses that contain private IP addresses for external domains:

# dnsmasq configuration
stop-dns-rebind

The dnsmasq manual documents stop-dns-rebind for rejecting private-address answers from upstream servers. Do not add rebind-localhost-ok as a default defense: it deliberately exempts loopback addresses. DNSSEC does not prevent an attacker from signing malicious answers for a domain they control.

Application-Level Defenses

Validate the Host header:

Internal web services should check the Host header in incoming requests. If a request arrives for an internal service but the Host header says attacker.com, it should be rejected:

# Place inside the http context. Adapt listeners and upstream for your service.
server {
    listen 8080 default_server;
    server_name "";
    return 444;
}
server {
    listen 8080;
    server_name router.local 192.168.1.1;
    location / {
        proxy_pass http://127.0.0.1:9000;
    }
}

The explicit default server rejects unmatched Host values; server_name alone would not. nginx documents this request selection behavior. Apply the rule to every reachable listener, including IPv6 or TLS listeners you add, and test allowed and unknown Host values.

Require authentication:

Never rely on network-level access control as the sole security mechanism for internal services. Every web interface should require authentication, even on the local network.

Browser and Network Defenses

• Use HTTPS on internal services where possible. The TLS certificate mismatch prevents the rebinding from completing.
• Disable unnecessary HTTP services on internal devices.
• Segment your network so that workstations cannot directly reach sensitive infrastructure like routers and management interfaces.
• Require IMDSv2 and disable IMDSv1 on AWS instances. AWS positions IMDSv2 as defense in depth that closes off the vast majority of SSRF-style paths to the metadata service, not as a guarantee, so pair it with least-privilege instance roles, Host-header validation, and network controls rather than treating it as the whole answer.

Mitigation Checklist

• DNS resolver configured to reject private IPs in responses for external domains
• Internal web services validate Host headers and reject unknown hostnames
• All internal web interfaces require authentication (not just network-level access)
• Cloud instances use IMDSv2 (or equivalent) for metadata access
• IoT devices and routers have non-default credentials
• Network segmentation prevents workstations from reaching management interfaces
• Development services on localhost bind to 127.0.0.1 rather than 0.0.0.0 (this limits exposure to other hosts on the LAN, but note it is not a rebinding defence: the victim's browser runs on that same host and can rebind straight to 127.0.0.1, so those services still need Host-header validation and authentication)

Common Misconfigurations

• Internal services with no authentication that assume network position equals authorization
• Routers and IoT devices with default credentials accessible via HTTP on the local network
• DNS resolvers without rebinding protection that happily cache private IPs for public domains
• Cloud instances using IMDSv1 which allows simple GET requests to the metadata service
• Development servers binding to 0.0.0.0 instead of 127.0.0.1, making them accessible from the local network

Ethical Note

DNS rebinding is a powerful technique that should only be tested in controlled environments. Set up a local network with test devices and your own authoritative DNS server. Never attempt rebinding attacks against networks or devices you do not own. The technique can be used to test the security of your own IoT devices, routers, and internal services, many of which still answer on the unsecured IoT protocols like MQTT and Telnet that remain widely exposed.

This article is part of the Complete Guide to DNS Attacks and DNS Security. See also: DNS Cache Poisoning, DNS Hijacking.