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 because the hostname has not changed — only the IP address behind it has.

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 a PUT request with a token — something that is harder to execute through DNS rebinding.

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
rebind-localhost-ok

This blocks the rebinding step by refusing to cache responses that map public hostnames to private IP ranges.

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:

# Nginx example — only accept requests for known hostnames
server {
    server_name router.local 192.168.1.1;
    # Reject requests with unrecognized Host headers
}

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.
• Use IMDSv2 on AWS instances to prevent metadata theft through rebinding.

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 only, not 0.0.0.0

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.

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