What is an open redirect?

Last reviewed June 2, 2026

An open redirect (CWE-601) is a flaw where an application redirects users to a destination taken from an unvalidated request parameter. Because the link starts on a trusted domain, attackers use it to lend credibility to phishing pages and to steal tokens passed in the redirect flow. The fix is to avoid user-controlled redirect targets and to restrict any redirects to an allowlist of approved destinations.

What an open redirect is

An open redirect occurs when a web application takes a destination from user-controllable input, such as a query parameter, and sends the browser to that location without validating it. The application acts as a redirector to any address the attacker chooses.

The danger comes from trust. The initial link points at a legitimate, recognizable domain, so users and security filters are more likely to trust it, even though the final destination is attacker-controlled.

How an open redirect works

An endpoint accepts a parameter that names where to send the user next, for example a return or next URL used after login.
The application redirects to that value without checking it against approved destinations.
An attacker crafts a link on the trusted domain whose parameter points at a malicious site.
The victim sees the trusted domain, follows the link, and is silently forwarded to the attacker site for phishing or further abuse.

Impact of an open redirect

On its own an open redirect is often rated lower severity, but it is a powerful building block. It boosts phishing success and can leak sensitive values when used inside authentication flows.

Convincing phishing, because the link begins on a trusted brand domain.
Theft of tokens or authorization codes when a redirect target is reachable inside an OAuth or single sign-on flow.
Bypass of naive URL filters and allowlists that only inspect the visible domain.
A pivot to other attacks, such as chaining into server-side request forgery or credential harvesting.

How to prevent open redirects

Avoid user-controlled redirect targets wherever possible, and prefer fixed, server-side destinations.
When redirection is required, validate the target against a strict allowlist of approved URLs or paths.
Use relative paths or map an opaque token to a known destination instead of accepting a full URL from the client.
Reject inputs that specify an external scheme or host, and normalize the URL before comparison to defeat encoding tricks.
In authentication flows, register and verify exact redirect URIs so tokens cannot be sent to an attacker-controlled destination.

Keep exploring

Frequently asked questions

Why is an open redirect dangerous if it only forwards the browser?: The link starts on a trusted domain, which lends credibility to phishing and helps it slip past filters. Inside authentication flows it can also leak tokens or authorization codes to an attacker-controlled destination.
How does an open redirect relate to server-side request forgery?: They differ in who makes the request. An open redirect forwards the user's browser, while server-side request forgery makes the server itself send a request. An open redirect can sometimes be chained to help reach an internal target.
Is checking that the URL contains my domain enough?: No. Substring checks are easily bypassed with crafted URLs and encoding, for example placing the trusted domain in a path or a username component. Validate against an allowlist and normalize the URL before comparing.
How should redirects after login be handled safely?: Restrict post-login redirects to internal paths, validate them against an allowlist, or map a server-side token to a known destination. For OAuth, register exact redirect URIs and reject any value that does not match.