DNS rebinding attacks and how browsers prevent them

How the attack works

DNS rebinding turns a public-looking domain into a way to reach your private network. The attacker registers a domain and serves a page whose script loads a resource from one of their own hostnames. Across requests, the attacker rapidly toggles the DNS answer for that hostname between a public IP and a private one such as 192.168.1.1 or 127.0.0.1. Because the browser trusts the origin (scheme, host, port) that stays constant even as the IP underneath it changes, the browser happily fetches from the "same origin" while the connection now lands on a local router, a printer, or an internal server. That turns the victim's browser into a proxy that can issue requests to, and steal responses from, devices on the user's local network.

A common and dangerous goal is to reach a router admin interface and change its DNS settings, after which the victim is funneled to phishing or other attacker-controlled sites. Because the attacking page and the local target share an origin from the browser's perspective, the browser grants cross-origin request privileges to a same-origin page, which is exactly the level of trust the attack exploits. This is why the origin model alone cannot protect against it, and why the TLS handshake and origin considerations are part of the wider picture.

Browser defenses

Since the origin does not change, browsers defend at the connection and policy layer rather than the origin layer. The current standard is Local Network Access (LNA), which restricts requests from a public website to local or loopback addresses behind user permission prompts. As of Chrome's rollout the model splits into two permissions: local-network for private-range addresses and loopback-network for localhost and 127.0.0.1, gated to secure contexts. LNA supersedes the earlier Private Network Access approach, which used CORS preflight requests as a local opt-in.

Two details matter for behaviour. First, a request is classified as local based on the IP the browser actually connects to, and checks are applied to each new connection, which is what catches a rebinding host that resolves differently request over request. Second, when the LNA permission is granted, browsers relax mixed-content blocking for local requests, because most local devices cannot obtain publicly trusted TLS certificates; without that exemption, an HTTPS page calling an HTTP local resource would simply be blocked as mixed content. For developers who know a URL will resolve locally, setting targetAddressSpace to local or loopback on a fetch() avoids the mixed-content check.

Protecting your services

LNA reduces the attack surface, but it does not make local services safe to expose unauthenticated. Defence in depth remains necessary:

• Require authentication (credentials, session, or a device-specific token) on router admin, internal dashboards, and any local endpoint; do not rely on "no one will ever connect here".
• Change defaults: default router passwords and default ports are known, so a rebinding victim is a guessing game away from full compromise.
• Keep local services on HTTPS where possible. LNA relaxes mixed content only when the destination is known local; using TLS still removes a whole class of interception and downgrade risk.
• Treat inbound requests to internal services as untrusted regardless of their apparent origin, because a browser on the LAN is not an attestation of identity.

Firewalls and origin lockdowns on the delivery side are covered in cloudflare lock down origin ip, and the DNS mechanics that make rebinding possible are the subject of the DNS TTL article. The consistent theme is that the browser layer helps, but the only durable protection is a local service that refuses unauthorised access in the first place.