DNS Rebinding Preserves Web Origin While the Network Destination Changes

A browser can treat two requests as same-origin even when the TCP connections behind them terminate at different IP addresses. The origin model is built from the URL scheme, host, and port. DNS resolution is a network operation beneath that identity. If a hostname resolves to one address and later resolves to another, the browser-facing origin can remain unchanged.

DNS rebinding exploits that separation. An attacker-controlled hostname can initially resolve to an attacker-controlled server that delivers script, then later resolve to an address reachable from the victim’s network. Subject to browser, resolver, transport, and target-service behavior, subsequent requests for the same hostname can then cross a network boundary without becoming cross-origin in the browser’s origin model.

The technique is not a general bypass of every browser control. Its effect depends on several independent checks, and modern clients can add protections beyond the traditional same-origin model. The core security property is narrower: DNS resolution does not make an IP address part of a web origin.

Origin identity does not pin a hostname to one address

For HTTP-facing browser security, an origin is identified by a tuple containing scheme, host, and port. A URL such as http://node.example:8080 therefore retains the same origin tuple while node.example continues to appear as the host, regardless of which address a resolver returns at a particular moment.

DNS, however, permits records to change. TTLs influence caching, but they are not an origin-security primitive. Resolution can also pass through browser caches, operating-system caches, recursive resolvers, and other components whose refresh behavior differs.

That creates two distinct identities:

A security design that treats those identities as interchangeable can place a network service behind a weaker boundary than intended.

The destination can move without a cross-origin transition

A simplified rebinding sequence starts with a hostname controlled by the attacker. Its first DNS response points to an Internet-facing server. The browser loads a document and script from that host, establishing an origin such as:

http://relay.example:8080

After the relevant DNS state changes or expires, a later lookup for relay.example can return a different address, potentially one on a loopback, private, or otherwise locally reachable network. A new connection can therefore target that address while the script still issues requests to the same URL origin.

The browser’s same-origin comparison has not gained an IP-address field. From that comparison alone, the script is still communicating with http://relay.example:8080.

This distinction matters for services that rely primarily on network placement. A management endpoint may never have been designed to accept requests initiated by arbitrary web content because operators assumed that an internal address was inaccessible to an Internet origin. Rebinding attacks that assumption at the name-to-address boundary.

HTTP authority remains an independent gate

Changing the resolved address does not normally rewrite the hostname carried at the HTTP layer. For HTTP/1.1, a request to the rebound hostname normally carries a Host value for that hostname. HTTP/2 and HTTP/3 use the :authority pseudo-header for the corresponding authority information.

That behavior can stop an attack when the destination service validates the authority it expects. A service configured only for admin.internal does not need to accept a request whose authority is relay.example.

Conversely, a service that accepts arbitrary host values, uses a default virtual host, or ignores authority for sensitive operations can remove this gate. Binding only to a private interface does not supply equivalent application-layer validation.

Host validation is therefore useful for services exposed through a browser-reachable HTTP stack, but it should match the deployment model. Reverse proxies and service meshes may legitimately transform routing metadata, so the component enforcing the check must use the authority value that represents the intended trust decision rather than an untrusted forwarded field.

HTTPS adds certificate identity to the path

TLS changes the feasibility of a rebound connection. If a script was loaded from an HTTPS origin, later connections to that same origin still need a TLS session acceptable for the hostname in the URL. A private service presenting a certificate for a different internal name will not satisfy normal browser certificate validation for the attacker-controlled hostname.

This makes a simple HTTPS-to-unrelated-HTTPS rebind materially different from a plain HTTP case. DNS control alone does not grant the attacker the private key used by the destination service, and certificate validation does not switch to the newly resolved IP address as the requested DNS identity.

The constraint is not a reason to treat DNS rebinding as an HTTP-only historical artifact. Local services, development interfaces, device administration endpoints, and mixed deployment environments can still expose plain HTTP or other browser-accessible surfaces. The relevant assessment must follow the actual transport and certificate configuration.

Network address checks require a clear resolution policy

Servers that accept user-supplied URLs sometimes defend against server-side request forgery by resolving a hostname and rejecting private addresses. DNS rebinding creates a related but distinct design issue: an address checked at one moment may not be the address used later.

The same principle applies when a client or proxy performs a network classification before connecting. A safe decision needs a defined relationship between validation and connection. If software validates one DNS result and then performs an independent resolution for the actual connection, the second result can fall outside the validated address set.

Possible designs include connecting to a specifically validated resolved address while retaining the intended hostname for protocol identity, or repeating address classification for every address that can be selected. The correct mechanism depends on the networking API, proxy path, TLS requirements, and failover behavior. A one-time hostname classification is not equivalent to constraining the eventual socket destination.

Browser network protections form a separate policy layer

Browser vendors can enforce restrictions that are stronger than the classic same-origin policy. Controls around requests from public contexts toward local or private network destinations can introduce permission, preflight, or blocking behavior depending on the browser and feature state.

Those controls should be treated as an additional enforcement layer rather than folded into the definition of origin. The origin tuple and the destination network classification answer different questions. Deployment behavior can also vary across browser versions and policy configurations, so an application should not infer a universal guarantee from one observed client.

This separation is useful operationally. Browser-side private-network controls can reduce exposure from hostile pages, while authority validation and authentication protect the service even when a request reaches it through another client or a browser configuration with different enforcement.

Authentication remains the decisive service boundary

DNS rebinding is most consequential when a locally reachable service treats reachability as authorization. A request arriving from a browser on the same machine or LAN can appear network-local even though the action originated in attacker-controlled script.

Sensitive endpoints need an authorization decision that survives that change in request provenance. Session credentials, explicit API authentication, anti-CSRF mechanisms where ambient browser credentials are involved, and strict request-origin policy can each address different parts of the problem. None is interchangeable with merely listening on a private address.

Origin validation can also provide a useful signal for browser-mediated state-changing requests, but its applicability depends on request type and service behavior. It is not a replacement for authentication, and services should not invent permissive fallbacks when the header is absent.

The durable boundary is therefore not DNS stability. It is the set of checks performed after the connection reaches the service: accepted authority, authenticated principal, authorized action, and any browser-request provenance policy required by the application. DNS rebinding exposes systems that assigned those responsibilities to network topology alone.