DNS Rebinding Preserves Web Origin While Changing Network Destination

A browser can load active content from a public server, keep that content in the same web origin, and later send requests bearing the same hostname to a private address. No origin tuple has changed. The network destination has.

That mismatch is the core of DNS rebinding. Web origins are principally identified by scheme, host, and port, while DNS maps a hostname to network addresses outside that tuple. When a name controlled by an attacker resolves differently over time, origin checks and network-location checks can describe two distinct security boundaries.

The result matters most when a service on a loopback, private, or otherwise locally reachable address assumes that remote web content cannot interact with it. DNS rebinding attacks that assumption by retaining the attacker’s hostname as the browser-visible authority while steering subsequent connections toward the local service.

Origin identity does not contain an IP address

For ordinary HTTP and HTTPS URLs, the web origin model uses a tuple of scheme, host, and port. A page at http://relay.example:8080/ therefore retains that origin while its hostname continues to be relay.example and the scheme and effective port remain unchanged.

DNS resolution is a separate operation. The browser or underlying networking stack resolves the host to an address when establishing a connection. A later connection can perform another resolution after cached DNS state expires or becomes unusable. If the resulting address differs, the origin tuple still contains the hostname rather than the selected IP address.

This separation is intentional. DNS names are stable application identifiers across address changes, load balancing, failover, and multi-address deployments. Binding web origin identity directly to one resolved address would conflict with those normal deployment properties.

The security consequence is equally direct: same-origin policy does not prove that two connections reached the same machine or the same network zone. It establishes a browser security principal from URL components.

Rebinding changes routing beneath a stable hostname

A rebinding setup requires control over DNS answers for a hostname. An initial resolution can point that hostname to an attacker-controlled public server. The server returns active content associated with the hostname’s origin.

A later resolution for the same hostname can return an address reachable from the browser’s network position, such as a loopback or private address. If the browser establishes a new connection using that answer, requests can reach a different server while still using the original hostname in the URL.

The attack is not simply a DNS cache trick. Effective exploitation depends on resolver behavior, browser DNS and connection caching, address selection, transport reuse, service behavior, and any browser or network controls that restrict transitions toward local address spaces. Long-lived connections can delay or prevent a fresh resolution. Intermediary DNS caches can also retain an earlier answer longer than the authoritative server intended.

Those conditions make rebinding timing deployment-specific, but they do not alter the architectural mismatch: URL authority and resolved network destination are different properties.

Host validation can stop the local service from accepting the borrowed authority

When an HTTP request reaches the local service, its request authority normally still names the attacker’s hostname. A service that expects only a fixed local hostname can reject the request before application actions are exposed.

This makes strict host or authority validation a useful boundary. A development daemon intended for localhost, for example, has no operational reason to accept arbitrary public DNS names merely because they currently resolve to a loopback address.

Permissive virtual-host defaults weaken that boundary. A server that accepts every Host value and routes all names to the same privileged application allows DNS ownership to influence which browser origin can address that application.

Host validation is not a substitute for authentication. A hostile process on the local machine may be able to send an accepted hostname directly, and non-browser clients are not constrained by browser origin policy. The check addresses the rebinding path by refusing an authority that the service did not intend to serve.

Network location is weak authentication

Many local administration interfaces and development services bind to loopback because that limits direct network reachability. That is a valuable exposure reduction, but it does not establish the identity of the software making a request.

A browser is itself a local process with network access. Remote content can cause that process to emit network traffic under browser rules. If a local service treats source address, loopback reachability, or private-network placement as sufficient authorization, it can assign privilege to requests without a strong application principal.

DNS rebinding turns this distinction into an application problem. The attacker does not need direct packet reachability to the local interface from the public Internet. The browser supplies local reachability.

Sensitive local services therefore benefit from explicit authentication and authorization even when their listener is intentionally restricted to local addresses. Capability-bearing random endpoints, authenticated sessions, operating-system mediated access, or other service-appropriate controls can make possession of network reachability insufficient by itself.

HTTPS changes the certificate constraint

HTTPS adds a significant condition because the server reached after rebinding must complete TLS for the hostname in the URL. A certificate valid for an attacker’s hostname does not automatically equip an unrelated local HTTPS service to authenticate as that hostname.

This limits straightforward rebinding against HTTPS services that present certificates for their own expected names and do not possess credentials valid for the attacker-controlled hostname. A TLS failure occurs before ordinary HTTP application processing can proceed.

The distinction does not make HTTPS a universal rebinding defense. A target may use plain HTTP, a deployment may have unusual certificate arrangements, or the relevant browser-facing mechanism may not depend on the exact conventional HTTPS setup. The precise transport and certificate configuration remains part of the threat model.

For HTTP services, there is no corresponding certificate check binding the DNS hostname to a cryptographic server identity. The hostname can remain stable at the browser layer while resolution selects a different endpoint.

CORS is not the primary boundary when the origin stays stable

Cross-Origin Resource Sharing controls selected cross-origin reads. DNS rebinding is notable because the browser-visible origin can remain the same across the destination change.

If script was loaded from http://relay.example and later requests continue to target http://relay.example on the same port, the request can remain same-origin even though DNS now directs the connection elsewhere. Treating CORS configuration as the main mitigation can therefore miss the mechanism.

A local service that emits no permissive CORS headers is still exposed to the core issue if the browser regards the request as same-origin with the attacking page. The relevant controls sit elsewhere: browser restrictions on local-network access, transport authentication, authority validation, and application authorization.

This also separates rebinding from conventional cross-origin attacks against a literal private IP URL. A request from a public origin to http://192.168.1.10 visibly crosses origins. Rebinding instead keeps the attacker-controlled hostname in the URL and changes what that hostname reaches.

Browser network controls add another address-space boundary

Modern browser security work has added controls around requests from less-private address spaces toward more-private destinations. Such controls can constrain classes of local-network requests that traditional same-origin processing did not distinguish solely from the URL origin.

These mechanisms add a network-address-space dimension rather than changing the basic origin tuple. Their exact enforcement, rollout state, request categories, and compatibility behavior are browser-dependent, so a local service should not treat browser policy as its sole authorization layer.

Network equipment can also affect exposure. DNS filtering, rebinding protection in resolvers, split-horizon policies, and endpoint controls may reject suspicious public-name-to-private-address mappings. Those defenses can reduce reachable attack paths, but they operate outside the application and can vary across client networks.

A service deployed on many developer machines or consumer networks cannot safely assume a uniform resolver policy.

The trust boundary spans naming and reachability

DNS rebinding is a boundary composition failure rather than a failure of one isolated browser check. The web origin model answers which URL principal owns active content. DNS answers where a hostname currently routes. Local addressing limits which network positions can establish connections. Application authorization decides which requests may perform sensitive actions.

Risk appears when those layers are treated as interchangeable. A stable origin does not imply a stable endpoint. A loopback peer does not imply trusted remote content was absent from the request path. A successful DNS lookup does not prove that the resulting server was the one that supplied the page earlier.

Robust local services keep those claims separate. They restrict listener exposure where practical, reject unintended request authorities, require application-level authorization for sensitive operations, and treat browser or resolver rebinding defenses as additional containment rather than as the only gate. DNS can then continue serving its routing role without silently becoming an authentication mechanism.