A service bound to a private address often feels insulated from the public web. An administrative panel on a home router, a development daemon on a laptop, or an internal HTTP endpoint may have no public route at all. Yet a browser on the same network can often reach it, and that browser also processes content from arbitrary public sites.
DNS rebinding exploits the seam between those facts. A hostile site can use a domain it controls, arrange for that name to resolve to different addresses over time, and attempt to make browser requests under one web origin reach a service that was never intended to receive traffic from public content.
The issue is not simply weak DNS. It is a boundary mismatch. Browser security primarily reasons about origins expressed through scheme, host, and port. Network operators often reason about trust through address ranges and routing. When a hostname remains constant while its resolved address moves from public infrastructure to a private destination, those models can diverge.
A stable origin can point at a different network
The same-origin model does not define an origin by the current IP address behind a hostname. For a conventional HTTP origin, the relevant tuple is the scheme, host, and port. DNS resolution supports reaching that host, but the resulting address is not normally part of the origin identity.
That distinction is essential to ordinary web operation. Large services change addresses, use content delivery networks, balance traffic across many endpoints, and move infrastructure without creating a new browser origin each time. Binding web identity directly to one address would conflict with routine deployment patterns.
DNS rebinding turns that flexibility into leverage. An attacker controls a domain such as probe.example and serves hostile browser code from a public address. The domain is then resolved, at a later point, to an address inside the target’s network, such as a loopback address or an RFC 1918 address. Requests still name probe.example, so the browser can regard them as requests to the same host even though the network destination has changed.
Practical behavior depends on DNS caching, browser networking logic, resolver behavior, connection reuse, protocol details, and defenses in the client or surrounding network. Rebinding is therefore not a promise that every browser will immediately switch destinations after a DNS answer changes. It is an attack pattern that becomes viable when name-to-address changes can influence later connections without creating a distinct origin.
Private reachability is not authentication
The most exposed services are often those that treat network placement as proof of authority.
A device management interface may listen only on a local subnet and assume that any client able to connect is trusted. A developer tool may bind to loopback and omit authentication because remote hosts cannot route to 127.0.0.1. An internal API may accept state-changing requests from office addresses without a user credential. Those assumptions can hold at the routing layer and still fail in the presence of a browser acting as a request-capable intermediary.
The browser does not need to give hostile code raw socket access for this to matter. Standard web capabilities can produce HTTP requests, WebSocket connection attempts, form submissions, image loads, and other network activity subject to different browser controls. The exact attack surface depends on the target protocol and on what response access the browser permits.
Cross-origin protections are important, but they are not a substitute for service authentication. CORS governs whether script can access certain cross-origin responses; it is not a general firewall that prevents every request from being sent. Some request forms can be transmitted even when response data remains unavailable to script. A state-changing endpoint that trusts mere reachability can therefore be at risk even when its responses are unreadable.
Rebinding can make the situation sharper because the attacker seeks to keep the browser-facing hostname stable. If a later connection under that hostname reaches the private service, a defense based only on the browser seeing a cross-origin destination may not capture the network transition that matters.
The Host field is useful evidence
HTTP services receive the hostname used for the request in the Host field for HTTP/1.1, with equivalent authority information in newer HTTP versions. A private service that expects only a narrow set of local names has an opportunity to reject unexpected authority values before performing sensitive work.
That matters in a rebinding scenario. The network connection may arrive at a private address, but the request can still carry the attacker’s public hostname. A router interface intended to answer only for router.home, for example, has little reason to accept an arbitrary internet-controlled hostname.
Strict host validation is therefore a valuable control for HTTP applications. The accepted set should reflect actual deployment names rather than broad suffix tests or acceptance of every syntactically valid host. Reverse proxies need equal care: if a proxy rewrites authority information before the application validates it, the application may lose useful evidence about the original request.
Host checks are not universal authentication. Legitimate deployments can require multiple names, and infrastructure layers can alter request metadata by design. Non-HTTP protocols do not necessarily provide the same field. A service also remains exposed to direct requests that already use an accepted name if other controls are absent. Host validation works best as one boundary check among several, not as a credential.
Address filtering has timing problems
A common defense pattern resolves a hostname, checks that the resulting address is public, then allows a connection. That can be appropriate in some server-side request controls, but DNS rebinding highlights a general problem with separating validation from use.
Names can resolve differently across time, resolvers, address families, or connection attempts. If security policy approves one resolution result while the network stack later performs another resolution for the actual connection, the check and the connection may refer to different destinations.
Browser implementations and network libraries can also maintain their own caches and connection pools. A policy that assumes one simple DNS lookup per request can miss the actual path taken by the client. Security decisions tied to destination class are strongest when the address used for the connection is the address that was evaluated, with redirects and subsequent connections receiving equivalent scrutiny.
Network-level DNS protections can reduce exposure by refusing suspicious answers that map public names to local or private addresses. Such filtering can be useful in managed environments, but it has operational trade-offs. Split-horizon DNS, private service discovery, VPNs, and legitimate public names that intentionally resolve to private addresses can all complicate a blanket rule.
The larger point is that DNS data is mutable routing input. Treating an earlier answer as a durable security assertion creates room for disagreement between policy and transport.
Browser defenses are becoming more explicit
Modern browsers have added or explored controls that distinguish requests into local networks from ordinary public-web traffic. The security goal is to stop a public origin from silently gaining access to more-private address spaces merely because the browser has local connectivity.
Such controls can materially reduce the rebinding surface, but application owners should not treat browser policy as the sole enforcement point. Browser behavior varies by version and request mechanism, embedded clients may not implement the same protections, and services often outlive the client assumptions present when they were deployed.
A local service that is safe only when every connecting browser classifies its network transition correctly has delegated a large part of its authorization model to software outside its control.
The stronger design starts from the service itself: sensitive actions require authentication, request authority is validated, state changes have appropriate anti-forgery properties, and the listener is exposed only as broadly as needed. Browser and network protections then provide additional containment rather than carrying the full security argument.
Loopback deserves the same scrutiny
Loopback services are easy to overlook because they are reachable only from the local machine. That restriction is valuable, but a browser runs on the local machine too.
Developer servers, desktop application bridges, local control APIs, notebook environments, debugging endpoints, and helper daemons may all expose HTTP or WebSocket listeners on loopback. If those services assume that a local TCP peer is automatically trusted, web content executing in the browser may challenge that assumption.
Authentication for a loopback service does not have to resemble a public account system. Depending on the architecture, a capability token, per-installation secret, explicit user approval, operating-system IPC, or another channel with stronger caller identity may fit better. The key property is that possession of local network reachability alone does not grant sensitive authority.
Binding only to loopback still has value. It blocks direct remote connections and reduces exposure substantially. The mistake is treating it as equivalent to authenticating the process or web origin initiating a local request.
Network location is context, not identity
DNS rebinding is a useful stress test for systems built around implicit trust. It asks what a service believes when a request arrives from a reachable path but carries an unexpected web origin context. Systems that can answer only with “the port is private” have placed too much security weight on topology.
Private addressing, loopback binding, DNS filtering, browser network restrictions, host validation, and service authentication operate at different layers. None needs to be discarded. The resilient architecture is the one that does not confuse them.
Network placement can reduce who is able to make a connection. It cannot, by itself, establish the identity or intent of code running inside an already connected browser. Once that distinction is explicit, DNS rebinding stops looking like an exotic DNS trick and becomes a more familiar security problem: authority was inferred from reachability at a boundary where reachability was never a reliable identity signal.