A browser tab can begin its life talking to a public server and, moments later, send requests under the same hostname to a device on a private network. No browser exploit is required for that transition. DNS can supply the change.
That property sits at the center of DNS rebinding. The attack is easy to reduce to a slogan about DNS answers changing, but the security consequence comes from a deeper mismatch. Browsers identify web origins primarily through scheme, host, and port. Network services often make trust decisions from the destination address, interface, or apparent local reachability. Rebinding creates a point where those two models no longer describe the same security boundary.
The result is especially relevant to administrative interfaces, development servers, local agents, embedded devices, and internal HTTP services that were designed on the assumption that an attacker on the public internet could not directly reach them.
A stable origin can lead to a different address
Consider an attacker-controlled hostname that initially resolves to a public address. A victim visits a page at that hostname, so the browser creates an origin associated with the site’s scheme, hostname, and port. JavaScript delivered by the public server runs in that origin.
The DNS record can then be changed, or answers can be served with short lifetimes, so a later resolution of the same hostname returns a private address such as one in 192.168.0.0/16 or a loopback address. Subject to browser, resolver, cache, and network behavior, a subsequent connection can target that new address.
From the browser’s origin perspective, the hostname has not changed. A request to the same scheme, hostname, and port remains associated with the same origin even though the network destination may now be a different machine.
This distinction matters because the same-origin policy is not an IP-address isolation mechanism. It restricts interactions between origins as browsers define them. It does not promise that a hostname will remain mapped to one address for the lifetime of a page.
DNS pinning and related browser defenses can constrain some rebinding patterns, but implementations and surrounding network behavior vary. Security architecture that depends on a browser permanently binding a hostname to its first observed address is therefore fragile.
Local reachability is not authentication
Many services historically treated network placement as a rough substitute for an identity check. A router administration panel might listen only on a LAN address. A development server might bind to loopback. A desktop application might expose an HTTP endpoint to local browser extensions or companion software. An internal dashboard might be reachable only through private routing.
Those restrictions can be useful. They reduce exposure and remain valuable as one layer of defense. The problem begins when reachability becomes the only authorization condition.
A service receiving a request through a rebound hostname can still see a connection arriving at its local interface. From the service’s perspective, nothing necessarily signals that the request originated from script supplied by a remote site. The browser acts as the network-capable intermediary.
This is a form of confused trust. The public attacker controls content in the browser, the browser has access to network locations unavailable to the attacker directly, and the private service grants authority based on that network location.
The risk is not limited to reading sensitive responses. State-changing endpoints can be dangerous even when browser policy prevents script from observing response data. A local service that accepts unauthenticated actions over HTTP may still process requests that alter configuration, trigger jobs, or invoke privileged operations.
Host validation changes the attack surface
A private HTTP service does not need to accept every hostname that happens to resolve to its address. Validating the request authority against a narrow set of expected hostnames can break a central condition of many rebinding attacks.
If a service is intended to be reached as admin.internal.example, a request carrying an attacker-controlled hostname should not be treated as equivalent merely because DNS directed that hostname to the same socket. The host value is part of the application’s public identity and should be checked accordingly.
This control is strongest when the accepted names are explicit and deployment-managed. Broad suffix rules, reflected host configuration, or permissive defaults can restore the ambiguity the check was intended to remove.
TLS can add another useful constraint. A browser connecting to a rebound private address over HTTPS still expects a certificate valid for the hostname in the URL. A private service normally does not possess a certificate for an attacker’s domain. Certificate validation can therefore obstruct the connection rather than silently transferring the existing web origin to the private endpoint.
That does not make HTTPS a complete rebinding defense. Local trust stores, development certificates, protocol downgrades, mixed deployments, and non-browser clients can alter the situation. The important property is that authenticated transport binds the connection to an expected service identity rather than relying only on destination reachability.
Browser controls add another boundary
Browser vendors have continued to tighten access from public web contexts toward local and private network resources. These controls address a real architectural gap: a public page should not automatically inherit the browser’s ability to contact every service reachable from the user’s machine.
Such protections can reduce exposure, but service owners still need independent controls. Browser policy evolves, clients differ, enterprise configurations can modify behavior, and not every request to a local service originates from a current mainstream browser.
A private service remains safer when it can reject an unauthorized request on its own. Authentication, authorization, host validation, request integrity controls, and constrained listening interfaces provide properties that do not depend on a particular browser enforcing a network boundary correctly.
CORS is often confused with this role. CORS governs whether browser script can access responses across origins under specified conditions. It is not a general authentication layer for the destination service, and it does not convert network location into a trustworthy principal. A state-changing endpoint that accepts unauthenticated requests can remain exposed even when response access is blocked.
Name resolution belongs in the threat model
Infrastructure diagrams often draw DNS outside the application security boundary, as if name resolution merely helps traffic find the right server. Rebinding shows that DNS can influence which server receives traffic while the browser continues to reason about a stable hostname.
That makes resolution behavior relevant anywhere an application grants privilege based on local placement. Internal control planes, device interfaces, local development tools, and desktop agents deserve particular scrutiny because they commonly combine powerful actions with intentionally narrow network exposure.
The useful design question is not whether a service is publicly routable. It is whether a hostile web origin can cause a client with broader reachability to speak to the service, and what authority the service grants when that happens.
Strong designs make the answer depend on authenticated identity and explicit authorization. Network placement can still reduce exposure, but it should not carry the full burden of proving who is allowed to act.
DNS rebinding is ultimately a boundary problem created by two valid abstractions meeting at an unsafe seam. The browser keeps faith with a hostname. The service keeps faith with a network location. Security improves when neither abstraction is asked to stand in for identity.