Prevent Unvalidated Redirects and Forwards by never sending users to a destination taken directly from untrusted input. Use allowlists for approved destinations, compare against relative application routes where possible, and reject external targets by default. Review login, logout, and post-action flows carefully, because attackers use open redirects for phishing, token theft, and trust abuse.
How to prevent unvalidated redirects and forwards
The safest pattern is to keep the redirect decision inside application logic, not in user-controlled input. Treat the destination as a server-side choice whenever you can, and when you must accept a return target, validate it against a small allowlist of approved paths or destinations. That prevents attackers from turning a convenience feature into a trust boundary bypass.
Use relative routes instead of full external URLs where possible, because relative targets are easier to constrain and less likely to be abused for phishing or token capture. If your application needs to support external destinations, reject them by default and only permit explicitly approved values. This is especially important in login, logout, password reset, and post-action flows.
Open redirect issues are part of the broader class of web application attack patterns covered in the Web Application Attacks Guide, and they often appear alongside other input-handling mistakes. If your redirect logic shares code with other request parameters, review whether the same parsing rules, decoding steps, or fallback behavior could widen the attack surface.
What makes redirect validation fail in practice?
Validation fails when developers trust a destination parameter because it looks harmless, such as a next, return, or url field. Attackers commonly exploit weak checks by using encoded values, alternate host formats, nested redirects, or application-specific edge cases that pass a superficial string test but still send the browser to an attacker-controlled location.
The real failure mode is not just “bad link” behavior, it is trust abuse. A crafted redirect can make a malicious site look like it was reached through a legitimate application, which helps phishing campaigns, intermediary token theft, and social engineering. Even a brief redirect chain can be enough to convince users that the destination is safe.
Where redirect and forward controls need the most care
Focus first on authentication and session-related flows, because that is where redirect abuse usually has the highest impact. A login page that accepts an arbitrary return target can be used to deliver a believable phishing path, and a post-authentication forward can leak state or create confusion about where the user actually landed.
Also review logout, consent, error handling, and “back to where you came from” behavior. Those code paths often get less scrutiny than primary application features, yet they can still carry sensitive user context. When the destination influences where the browser goes after a security-relevant action, treat that parameter as part of the security design rather than a convenience feature.
For teams that also manage API keys or other secrets in adjacent workflows, redirect safety is only one part of the broader exposure story. If an application action can move a user or token-bearing browser session to an unexpected destination, the surrounding secret handling and session design deserve the same review discipline as the redirect check itself, which is why the API Key Management Guide is relevant when those flows intersect with credential handling.
Risk and Threat Considerations
unvalidated redirects and forwards are low-friction abuse paths because they turn a trusted application into an attacker-controlled handoff point. The main risks are phishing credibility, session or token exposure through browser navigation, and user confusion that weakens trust in the application’s own URL space.
Failure mechanism: The application accepts a destination from untrusted input, then performs a redirect or forward without sufficiently constraining where the browser or server-side flow can go.
Impact: Attackers can chain the trusted domain into a malicious journey, increase phishing success, and in some workflows capture tokens, sensitive parameters, or user actions that were assumed to stay within the application.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V10 — OAuth and OIDC | Redirect handling is central to auth flow integrity and return-target control. |
| Recommendation — Validate return targets and state handling in authentication flows to prevent open-redirect abuse. | ||
| NIST SP 800-53 Rev 5 | AC-4 — Information Flow Enforcement | Redirects govern where users and sessions are sent, which is an information-flow decision. |
| SC-23 — Session Authenticity | Open redirects can undermine user confidence in trusted navigation during sensitive sessions. | |
| Recommendation — Enforce approved destination rules for application-driven navigation and flow control. Protect session-facing flows from destination tampering and trust abuse. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Weak redirect validation is a common application misconfiguration that attackers exploit. |
| Recommendation — Harden redirect handling so user-supplied destinations cannot alter trusted flow behavior. | ||
| MITRE ATT&CK | T1566 — Phishing | Open redirects are often used to make phishing links look trustworthy. |
| Recommendation — Hunt for redirect abuse that increases phishing credibility and delivery success. | ||
Practitioner Guidance
What to verify: Confirm that every redirect or forward is either server-selected or validated against a short allowlist of approved routes. If the application accepts external targets at all, test that they are rejected by default and that encoded, alternate, or chained forms do not bypass the check.
Common mistake: Do not rely on simple substring checks, domain-name comparisons alone, or “safe-looking” parameter names. Those controls often pass the obvious cases while failing on edge-case parsing, which is exactly where open redirect abuse tends to hide.
Practitioner takeaway: The best test is whether a malicious user can still influence where trust is handed off. If they can, even indirectly, the redirect is still part of your attack surface and should be treated as a security control, not just a usability feature.