An open redirect is when an app takes a user-supplied value and uses it to redirect the browser without restricting where it can point. Sites legitimately redirect (after login, or onward to a page in a URL parameter), but if the destination isn't validated against allowed locations, an attacker crafts a link on the trusted domain that quietly forwards the victim to an attacker-controlled site. It rarely breaches the site itself - its value is what it enables: (1) far more convincing phishing, because the link genuinely starts on a familiar domain and passes casual inspection and some filters; and (2) chaining - helping steal tokens in OAuth/SSO by redirecting the authorization response to an attacker, and assisting other redirect-dependent attacks. Fix: don't derive redirect targets from user input; where needed, validate against a strict allowlist, prefer relative paths or a server-side token→destination map, and show an interstitial for unavoidable external redirects. Blocklists fail. Related: OAuth/SSO testing.
// 01 What an open redirect is
An open redirect is a vulnerability in which a web application takes a user-supplied value and uses it to redirect the browser to another location without properly restricting where it can point. Many sites legitimately redirect users - for example after login, or to send them onward to a page passed in a URL parameter (?next=, ?returnUrl=, ?redirect=). But if the destination is taken from the request and not validated against a set of allowed locations, an attacker can craft a link on the trusted site that quietly forwards the victim to an attacker-controlled site. The important point: the link starts on the legitimate, trusted domain. That's what makes it valuable to attackers - even though the vulnerability itself doesn't directly compromise the site's data, it lends the site's credibility to the attack.
// 02 Why a “harmless” redirect is dangerous
Open redirects are dangerous because of what they enable, not what they do alone:
Convincing phishing
The victim sees a link that genuinely begins with a trusted domain, is reassured, clicks, and is silently forwarded to a look-alike credential-harvesting page.
Filter evasion
Because the initial domain is real, the link passes casual inspection and can slip past some filters.
OAuth / SSO token theft
Chained into auth flows to help steal tokens by redirecting the authorization response to an attacker.
Attack stepping stone
Assists other attacks that rely on controlling a redirect target.
So while an open redirect rarely breaches a site by itself, it's a valuable stepping stone - which is why it's worth fixing even when a scanner rates it “low.”
// 03 How it's used in phishing
An open redirect lets the attacker borrow the credibility of a trusted domain. The attacker finds a redirect endpoint on the legitimate site that accepts a destination in a parameter, then builds a link to that endpoint with the destination set to their malicious page. The link they send genuinely starts with the trusted site's address, so it looks safe. When the victim clicks, the trusted site immediately redirects their browser to the attacker's look-alike login or payment page, where their details are captured. Because the visible, clicked link was on the real domain, the victim's trust in that brand transfers to the attack - which is exactly why open redirects are prized in credential-phishing campaigns, alongside newer social-engineering tricks like deepfake voice phishing. It's the reason a redirect endpoint is a brand-safety issue, not just a technical one.
// 04 How to prevent open redirects
The reliable fix is to avoid using user-supplied input to determine a redirect destination at all. Where redirection based on a parameter is genuinely needed, validate the destination against a strict allowlist of permitted locations rather than accepting arbitrary URLs. A common safe pattern is to redirect only to relative paths within your own site, or to map an opaque token or short identifier to a known destination server-side so the raw URL is never taken from the client. Blocklisting particular strings is unreliable - attackers can encode and disguise URLs in many ways (protocol-relative URLs, encoded characters, embedded credentials, and more). And where an external redirect is unavoidable, showing an interstitial page that makes clear the user is leaving the site is a useful additional safeguard. It's a small check with outsized value - a redirect endpoint is a routine but easily-missed finding in a web application penetration test.
// 05 Frequently asked questions
What is an open redirect vulnerability?
A vulnerability where a web application takes a user-supplied value and uses it to redirect the browser to another location without restricting where it can point. Sites legitimately redirect - after login, or onward to a page passed in a URL parameter - but if the destination isn't validated against allowed locations, an attacker can craft a link on the trusted site that quietly forwards the victim to an attacker-controlled site. The link starts on the legitimate domain, which is what makes it valuable even though it doesn't directly compromise the site's data.
Why are open redirects dangerous if they don't steal data?
Because of what they enable. Their primary use is convincing phishing: a victim sees a link that genuinely begins with a trusted domain, is reassured, clicks, and is silently forwarded to a look-alike page that harvests credentials. Because the initial domain is real, the link passes casual inspection and some filters. Beyond phishing they can be chained into more serious attacks - helping steal tokens in OAuth and SSO flows by redirecting the authorization response to an attacker. So while rarely a breach alone, an open redirect is a valuable stepping stone.
How is an open redirect used in phishing?
It lets the attacker borrow the credibility of a trusted domain. They find a redirect endpoint on the legitimate site that accepts a destination in a parameter, then build a link to it with the destination set to their malicious page. The link genuinely starts with the trusted address, so it looks safe. When the victim clicks, the trusted site redirects their browser to the attacker's look-alike login or payment page, where details are captured. Because the clicked link was on the real domain, the victim's trust in that brand transfers to the attack.
How do you prevent open redirects?
Avoid using user-supplied input to determine a redirect destination. Where parameter-based redirection is genuinely needed, validate the destination against a strict allowlist rather than accepting arbitrary URLs. A safe pattern is to redirect only to relative paths within your own site, or to map an opaque token to a known destination server-side so the raw URL is never taken from the client. Blocklisting strings is unreliable because URLs can be encoded and disguised. Where an external redirect is unavoidable, an interstitial page warning the user they're leaving the site is a useful safeguard.
// 06 Related reading
- OAuth & SSO security testing — where redirect handling is critical.
- Deepfake & voice phishing — the broader social-engineering picture.
- Web application penetration testing — where open redirects are found.