Open Redirect Vulnerabilities: What They Are and How to Test For Them

A login flow that redirects back to wherever the user came from is a normal, useful feature - right up until it accepts anyURL, at which point your trusted domain becomes free phishing infrastructure for someone else's attack.

What an Open Redirect Actually Is

A page like yoursite.com/login?returnTo=/dashboard is fine - it only ever sends the user somewhere on your own site. An open redirect is the same pattern with no validation on the destination:

yoursite.com/login?returnTo=https://attacker-site.com/fake-login

The link starts with your real, trusted domain - which is exactly what makes it convincing in a phishing email or message - but silently forwards the victim to a site under the attacker's control the instant they click it.

Why This Is Worse Than It Sounds

• It borrows your domain's reputation. Email security filters and cautious users both check the domain in a link before clicking - an open redirect passes that check while still ending up somewhere malicious.
• It can be chained with other attacks. Some OAuth flows validate a redirect URI loosely enough that an open redirect on the same domain can be abused to leak authorization codes or tokens to an attacker-controlled endpoint.

How to Test For It

Look for any parameter that controls where the user ends up after an action - login, logout, checkout completion, unsubscribe links - and try substituting a fully-qualified external URL. If the browser ends up on that external site, the endpoint is vulnerable.

How to Fix It

1. Only allow relative paths

The simplest fix: reject any redirect target that isn't a relative path starting with / (and not //, which browsers can interpret as protocol-relative and therefore external).

2. Or validate against an explicit allowlist

If you genuinely need to redirect to specific external destinations, check the target against a known list of allowed domains rather than accepting anything.

3. Never trust the Host header for this either

A redirect built from the request's own Host header (rather than a hardcoded domain) inherits the same problem if that header can be spoofed by a misconfigured proxy in front of your app.