Unvalidated Redirects and Forwards

How unvalidated redirects and forwards work

Unvalidated redirects and forwards are not a bug in routing alone, they are a trust failure in how an application handles destination input. The application accepts a return URL, next parameter, or internal forward target and sends the user where that value points instead of where the application policy intended.

This matters because the browser or server still appears to be behaving normally, which makes the abuse easy to miss in testing and in user workflows. The redirect can send a victim to a lookalike login page, while a forward can quietly move execution into a protected path that the user should never have reached directly.

Why this weakness is dangerous

The danger comes from the fact that the application is borrowing its own trust boundary to vouch for an attacker-chosen destination. That can support phishing, session theft, token capture, and access-control bypass when a user assumes the destination is safe because it came from a legitimate site flow.

Open redirect chains can also be used as an intermediate step in broader attacks, such as making malicious links look first-party, laundering a user through a trusted domain, or steering a browser through a sequence that hides the real landing page. NHIMG’s Web Application Attacks Guide covers open redirect alongside other common web attack patterns that abuse input handling and trust decisions.

How organisations find and reduce exposure

Exposure usually sits in login flows, post-auth return URLs, deep-link handlers, and any feature that accepts a destination from request parameters, headers, or hidden form fields. Teams should review those code paths, identify where untrusted input influences navigation, and confirm whether the application allows only a fixed allowlist of destinations.

Reviewing internet-facing entry points is especially important because attackers often probe public URLs first, then test whether they can redirect users to external domains or force internal forwards into sensitive application states. For broader web-app hardening context, the same guide is useful for mapping this issue to adjacent weaknesses such as request manipulation and access-control failures.

Detection, verification, and post-exploitation review

Testing should confirm that the application rejects arbitrary absolute URLs, normalises relative paths safely, and does not expose internal forward targets that reveal routing structure. Security review should also verify whether redirect destinations are logged, because logs help distinguish ordinary navigation from suspicious off-domain jumps.

After suspected exploitation, review authentication events, session activity, and any login or consent handoff that used a redirect parameter. If an attacker used the weakness to capture tokens or abuse a session handoff, the compromise review should extend to the affected account state and any downstream actions taken through that browser session.

Risk and Threat Considerations

Unvalidated redirects and forwards are dangerous because they let an attacker reuse a trusted application as a delivery mechanism for deception or abuse. The weakness can support credential harvesting, session theft, and access-control bypass even when the vulnerable application is not itself the final target.

Failure mechanism: The application accepts a destination from untrusted input and treats it as authoritative, so the attacker controls where the user is sent or which internal handler processes the request.

Impact: Users can be routed to malicious pages under a trusted brand, security controls can be bypassed through unintended internal execution paths, and downstream compromise can begin from a link that appears legitimate.

Practitioner Guidance

Why practitioners should care: Redirect and forward handling is part of the application trust boundary, not a cosmetic navigation feature. If the destination is user-controlled, the control design should treat it as attacker-supplied data and verify it before any redirect or dispatch occurs.

What to watch for: Parameters such as return, next, redirect, url, and goto often reveal these flows, but the most important test is whether the application enforces an explicit allowlist of destinations rather than trying to blacklist bad ones. Internal forwards deserve the same scrutiny as browser redirects because they can expose protected application logic.

Related resources from NHI Mgmt Group

• Who is accountable for phishing defences when trusted redirects are abused?
• How should teams govern DNS redirects in production environments?
• What should organisations check before using cross-domain redirects?
• What breaks when certificate metadata is self-reported and unvalidated?