DOM-Based Redirect

How DOM-Based Redirect Works

DOM-based redirect happens entirely in the browser. The page reads or builds a destination URL from DOM data, then navigates the user without a server-side redirect decision. That makes the control point the client-side script and its input handling, not the server route that originally delivered the page.

The pattern is often introduced through convenience code, such as reading query parameters, hash fragments, form values, or other page state and using them to set window.location or a similar navigation sink. The issue is not the redirect mechanism itself, but the trust placed in data that the browser can influence or an attacker can shape.

Why It Is Dangerous

When the browser becomes the redirect decision-maker, attacker-controlled values can push users to hostile sites that look legitimate, support phishing flows, or chain into further abuse. A DOM-based redirect can also be used as a trusted jump point from a reputable domain, which is especially effective when users see the original site before the navigation happens.

Because the redirect is assembled at runtime, the vulnerable logic may be missed by server-side scanning or code review that focuses only on HTTP redirect headers and response handling. The dangerous part is the client-side trust boundary: once untrusted data reaches a navigation sink, the browser will often follow it immediately.

For client-side script injection and redirect abuse, the core prevention problem is the same as broader DOM XSS hygiene: keep untrusted data away from dangerous sinks and use hardened browser controls where they apply. NHIMG’s Cross-Site Scripting (XSS) Prevention Guide and Trusted Types and DOM XSS Prevention Guide are useful references for understanding the same client-side trust boundary from a prevention angle.

Common Failure Patterns

Open redirect abuse usually appears when code accepts a fully qualified target URL, or when a partial target is concatenated into a final destination without validation. Even when the intent is benign, such as redirecting after login or after an error page, the navigation sink becomes risky if the source of the destination is not tightly constrained.

Another failure pattern is assuming that browser-side normalization, encoding, or URL parsing will make the target safe. In practice, subtle differences in parsing, protocol handling, and DOM APIs can turn a seemingly harmless value into an unexpected navigation target or a script-assisted redirect path.

This pattern overlaps with broader web application control validation, and attacker behaviour often follows the same discovery and abuse logic seen in controlled security testing. Breach and Attack Simulation (BAS) Guide is relevant when teams want to validate whether their web controls, monitoring, and user protection measures actually detect redirect abuse paths.

How to Reduce Exposure

The safest design is to avoid taking a destination directly from user-controlled input. Where a redirect is required, restrict destinations to an allowlist of known internal paths or approved external locations, and ensure the browser only receives a value that the application has already validated.

Security teams should also review code paths that build URLs from DOM state, including fragments and query strings, because these often appear in post-login flows, help centres, and single-page applications. If a redirect cannot be removed immediately, a compensating control is to narrow the accepted target space and make any externally visible navigation explicit to the user.

When redirect logic lives in JavaScript, treat it as part of the application security surface, not as harmless front-end glue. That means reviewing sink usage, checking the provenance of every redirect input, and testing whether browser-side logic can be steered into unsafe destinations.

Risk and Threat Considerations

DOM-based redirect creates a phishing and navigation-abuse risk because the browser can be sent to an attacker-chosen destination after the user has already trusted the original page. It is especially dangerous when the redirect path is used in login, support, password-reset, or other user-trust flows.

Failure mechanism: An attacker supplies or manipulates a DOM value that client-side code later uses as a navigation target, turning a trusted page into a redirector.

Impact: Users can be steered to credential theft pages, chained social-engineering flows, or other malicious destinations, while the original domain gives the redirect added credibility.

Practitioner Guidance

What to watch for: Review any client-side code that reads URLs, query parameters, fragments, or other DOM values before navigation. If the target is not strictly constrained to known-safe destinations, treat the flow as a security issue rather than a UX convenience.

Governance implication: Redirect logic should have an owner in the application security review process, because the risk sits at the intersection of front-end code, user trust, and phishing resistance. Teams should test these flows during secure development reviews and validate them as part of web application hardening.

Related resources from NHI Mgmt Group

• Client-Side URL Redirect (DOM-Based Open Redirect)
• How should security teams detect OAuth redirect abuse in browser-based phishing campaigns?
• How can identity teams reduce exposure to redirect-based phishing without relying on blocklists?
• What breaks when redirect URLs are not tightly controlled in OAuth-based integrations?