A browser loads script from an attacker-controlled hostname while that name resolves to a public server. Seconds later, another lookup for the same hostname returns a private address such as an RFC 1918 destination. The browser still sees the same scheme, host, and port in the URL, yet a subsequent connection can terminate at a different machine.
That gap between web origin identity and network destination is the basis of DNS rebinding. The same-origin policy primarily reasons about origins expressed through URL components; it does not define an origin by the IP address selected by DNS for each connection. An attacker who controls both a hostname and its DNS answers can exploit that separation when a browser is permitted to resolve the name to a target reachable from the user’s network.
The attack does not make arbitrary private systems routable. It uses connectivity the browser already has. Its force appears where a service assumes that requests arriving from a local network, loopback-adjacent environment, or otherwise restricted address space do not need a stronger application-layer authorization decision.
One hostname can lead to different connection endpoints
DNS answers are not permanent bindings. Resource records carry TTL values, caches expire entries, authoritative servers can change answers, and clients may perform fresh resolution as connections are created. A hostname controlled by an attacker can therefore produce different address answers over time.
A typical rebinding sequence starts with an address that reaches infrastructure controlled by the attacker. That first destination can serve HTML and JavaScript under a hostname such as node.example.invalid. At a later resolution point, the authoritative DNS service returns an address belonging to a private or otherwise locally reachable target.
The browser’s origin calculation does not become a comparison between the first and second IP addresses. For an ordinary URL origin, the relevant tuple remains the scheme, hostname, and port. If those components stay constant, a changed DNS result does not by itself create a new origin.
This is the architectural mismatch: DNS maps a stable name to a potentially changing network endpoint, while browser isolation uses the stable name as part of its security identity. DNS rebinding turns that normal indirection into a path across a network trust boundary.
Several implementation details can disrupt a proposed sequence. DNS caching can retain an earlier answer. Existing HTTP connections can be reused without another lookup. Browser networking layers can apply private-network restrictions or other defenses. Resolver behavior can alter TTL handling. None of those details changes the core mechanism, but each affects whether a specific rebinding attempt reaches the intended destination.
The browser supplies reachability the public server lacks
A private service at 192.168.1.20 may be unreachable from the public Internet while remaining reachable from a browser running on the same LAN. The attacker’s server cannot directly open a route to that address, but attacker-supplied browser code may cause the browser to make requests using its local routing context.
Rebinding is therefore not equivalent to bypassing a firewall at the packet-forwarding layer. The perimeter can continue to block unsolicited inbound Internet traffic. The browser is already inside that perimeter and initiates the connection itself.
This distinction matters for threat modeling. A rule that says “this port is not exposed to the Internet” describes network reachability, not application authorization. If hostile web content can induce a local browser to contact the port, the service may still receive adversarially influenced traffic.
The resulting exposure depends on what the service accepts. A read-only status endpoint has a different consequence from an administrative interface that changes configuration. A protocol that rejects unexpected HTTP semantics presents a different surface from an HTTP API. Authentication, CSRF defenses, origin validation, host validation, and browser-side restrictions can each change the outcome.
DNS rebinding supplies a route for requests; it does not automatically supply credentials, parse arbitrary protocols, defeat cryptography, or guarantee readable responses.
Host validation can bind HTTP traffic back to the intended name
An HTTP server receives a host authority identifying the target name requested by the client. A service that is intended to answer only for a fixed set of names can reject unexpected values instead of treating every Host value as interchangeable.
This creates a useful check against a common rebinding shape. The attacker-controlled hostname remains in the URL after its address changes. When the browser connects to a private HTTP service, the request still identifies that attacker-controlled name. If the private service accepts requests only for its configured hostnames, it can reject the request before privileged application behavior occurs.
Host validation is not a universal substitute for authentication. A service intentionally reachable through many dynamic names may have difficulty applying a narrow allowlist. Reverse proxies can also change the authority information presented to an upstream, so the enforcement point must match the actual deployment architecture. Services that do not use HTTP have no HTTP Host field to validate.
The control is strongest when the service has a clear canonical authority and rejects traffic that claims another one. It converts a routing accident into an application-visible mismatch.
Local address checks are weak authorization signals
A service bound to a private interface often carries an implicit policy assumption: only trusted local actors can reach it. DNS rebinding attacks the inference rather than the bind operation.
Source addresses do not reliably identify the human or application that caused a browser request. From the target’s perspective, the connection may legitimately originate from a machine on the local network. Network topology has authenticated reachability, at most, not the intent behind the request.
The same issue appears with services that grant broader privileges to “local” clients. If the privilege decision depends solely on source location, a browser acting on hostile remote content can become a confused intermediary between an Internet origin and a local service.
Application authentication narrows this gap. A privileged operation can require a credential that hostile page content does not possess, with authorization evaluated against the requested action rather than inferred from the client’s subnet. The credential mechanism still has to resist ambient browser behavior: cookies, client certificates, and other automatically attached credentials have different cross-origin and request-context properties.
A service should therefore distinguish two separate claims. “The connection arrived through a local route” can be operationally useful. “The requester is authorized to perform this action” needs an authorization mechanism suited to the service.
Origin checks and CORS address different parts of the exchange
Browser cross-origin controls are often discussed alongside rebinding, but they do not collapse into one mechanism.
CORS governs whether script can make certain cross-origin requests and access responses under browser policy. DNS rebinding attempts to preserve the attacker’s hostname as the URL host, so the browser may continue to classify requests as same-origin even after DNS directs a connection elsewhere. A service cannot assume that the absence of permissive CORS headers alone blocks every rebinding path.
The Origin header can give an HTTP service additional context for requests that carry it. A service with a fixed expected web origin can reject unexpected origins on sensitive operations. That check must account for the fact that not every request type carries Origin, and application behavior must not silently treat a missing value as equivalent to an approved one where the header is required by policy.
CSRF controls can also matter when a browser automatically carries credentials to the target. Their protection depends on the credential model and request flow. They do not repair a service whose sole authorization rule is local network location.
These controls overlap at the edges but protect different boundaries. Host validation asks whether the request was addressed to a name the service serves. Origin validation asks about the web context that initiated applicable requests. Authentication establishes a principal or possession claim. Authorization decides whether that principal may perform the operation.
DNS pinning defenses trade flexibility for destination stability
A client or intermediary can defend against rebinding by constraining changes in resolved address class or by retaining a validated address binding for an appropriate period. Such mechanisms are often described as DNS pinning, though exact behavior varies across products and networking stacks.
The security objective is to prevent an attacker-controlled name from moving a browser connection from an acceptable destination to a protected one while retaining the same web identity. A policy might reject resolutions to loopback, link-local, private, or other sensitive ranges for contexts that began on a public destination.
Address classification is more complicated than a single public-versus-private test. IPv4 and IPv6 contain multiple special-purpose ranges, local deployments use custom routing, proxies can perform resolution on another machine, and globally scoped addresses can still reach sensitive infrastructure. A destination filter must reflect the actual network boundary it intends to enforce.
Pinning also interacts with legitimate DNS behavior. Load balancing, failover, content delivery, and service migration can intentionally change address sets. Holding an address indefinitely would break ordinary operation and can create availability problems. Effective defenses therefore need a bounded security policy rather than the assumption that a hostname has one permanent address.
Resolution location changes the trust boundary
The component performing DNS resolution matters. A browser using a forward proxy may send a hostname to the proxy, leaving resolution and connection establishment to that proxy. A local browser connecting directly resolves in a different network context. Secure DNS transport changes who can observe or tamper with resolver traffic, but it does not stop the authoritative owner of a hostname from legitimately changing that hostname’s answers.
This makes DNS rebinding distinct from DNS cache poisoning. Rebinding does not require forging a resolver response or corrupting a cache. The attacker can publish valid DNS data for a domain the attacker controls. DNSSEC likewise authenticates DNS data; it does not assert that successive authenticated address answers must remain in one network zone.
The key question is not merely whether the DNS answer is authentic. It is whether the consumer is willing to use the resulting destination under the security identity already attached to the hostname.
That distinction is especially relevant in systems that fetch URLs on behalf of users. Server-side request forgery defenses can face a related time-of-check versus time-of-use problem if validation resolves a hostname once but the later connection resolves it again. The execution environment differs from a browser rebinding attack, yet both expose the risk of validating a name-to-address relationship that can change before use.
Browser restrictions reduce exposure but do not erase service responsibility
Modern browser networking policies can restrict requests from less-private address spaces toward more-private destinations, and browser vendors have changed such controls over time. Deployment details, request modes, browser versions, and policy state affect the protection available in any particular environment.
A local service cannot safely derive its authorization model from an assumption that every possible client is a current browser with one specific network policy enabled. Native applications, embedded web views, older clients, automation, extensions, proxies, and non-browser HTTP stacks may reach the same endpoint under different rules.
Browser defenses are valuable because they can block a broad class of hostile web-to-local transitions before traffic reaches the service. Service-side controls remain important because they bind protection to the resource being protected.
The robust boundary is explicit: validate the authority a service is meant to answer for, authenticate privileged callers where feasible, authorize sensitive actions, and treat network location as context rather than proof of permission. DNS can then continue to perform its intended role as a mutable naming layer without silently carrying the full weight of application trust.
A stable origin name is not a stable network principal
DNS rebinding works at a seam between two legitimate abstractions. Web security gives a hostname durable significance inside an origin. DNS gives that same hostname mutable routing significance. Neither property is defective in isolation.
The failure appears when a service treats the destination network as a trusted enclave while a browser can preserve an attacker-controlled web identity across a change in DNS destination. At that point, a name controlled outside the enclave can become a route to a service inside it.
Controls are strongest when they attach policy to the layer making the decision. DNS and browser networking can constrain dangerous destination transitions. HTTP services can validate the authority they serve. Applications can authenticate callers and authorize operations. Firewalls can limit direct reachability. Each control covers a distinct part of the path.
The security trade-off is therefore not between mutable DNS and a perfectly fixed alternative. Operational networks require changing addresses. The safer design is to avoid treating a transient name-to-address mapping, or the locality of the resulting socket, as sufficient evidence of application authority.