What Is an Open Redirect?

An open redirect is a vulnerability where a web application accepts a user-controlled URL parameter and redirects the user to it without validation. Attackers exploit this to redirect victims to malicious sites while the link appears to come from a trusted domain.

It is one of the most underestimated web vulnerabilities. It does not directly compromise your server, but it weaponizes your domain's reputation against your users.

How Open Redirects Work

Many web applications use URL parameters to redirect users after login, logout, or other actions:

https://trusted-bank.com/login?redirect=/dashboard

This is normal and safe when the redirect target is validated. It becomes an open redirect when the application blindly follows any URL in that parameter:

https://trusted-bank.com/login?redirect=https://evil-phishing-site.com/fake-login

The user sees trusted-bank.com in the link. Their browser navigates to trusted-bank.com. Then the server immediately redirects them to the attacker's site. The victim may not notice the domain change, especially on mobile.

The Attack Flow

1. Attacker crafts a URL:
   https://trusted-bank.com/login?return=https://evil.com/fake-login

2. Attacker sends this link via email/social media:
   "Click here to verify your account"
   (link points to trusted-bank.com -- looks legitimate)

3. Victim clicks the link:
   - Browser goes to trusted-bank.com (trusted domain, valid SSL)
   - Server redirects to evil.com/fake-login
   - Victim sees a login page that looks identical to trusted-bank.com
   - Victim enters credentials on the attacker's site

4. Attacker captures credentials
   - Optionally redirects victim back to real site
   - Victim may never realize what happened

OWASP Classification

The Open Web Application Security Project (OWASP) classifies unvalidated redirects and forwards as a significant web application security risk. It appeared in the OWASP Top 10 as its own category (A10) in 2013, and while it was merged into broader categories in later editions, the vulnerability remains common and dangerous.

OWASP identifies two variants:

Common Vulnerable Patterns

URL Parameter Redirects

The most common pattern. Look for parameters like redirect, url, next, return, goto, dest, continue, redir, or returnTo:

/login?redirect=https://evil.com
/auth/callback?next=https://evil.com
/logout?returnTo=https://evil.com
/click?url=https://evil.com

Header-Based Redirects

Some applications redirect based on the Referer or custom headers:

GET /dashboard HTTP/1.1
Host: example.com
Referer: https://evil.com

# Server redirects to Referer on auth failure
HTTP/1.1 302 Found
Location: https://evil.com

Path-Based Redirects

Less common but possible. The redirect target is encoded in the URL path:

/redirect/https://evil.com
/go/aHR0cHM6Ly9ldmlsLmNvbQ==  (base64 encoded)

Real-World Impact

Open redirects have been found in major platforms:

• OAuth flows: Many OAuth implementations redirect to a redirect_uri parameter after authentication. If the allowed redirect URIs are not strictly validated, attackers can steal authorization codes.
• Single Sign-On (SSO): SSO systems frequently use redirect parameters. An open redirect in an SSO provider affects every application that trusts it.
• Email unsubscribe links: Marketing platforms that redirect through tracking URLs. An open redirect here weaponizes email campaigns.
• URL shorteners: Services that redirect based on user input without validation are open redirects by design, mitigated only by the expectation that the destination is unknown.

How to Find Open Redirects

Manual Testing

Automated Scanning

Include open redirect checks in your security scanning pipeline. Most web application scanners (Burp Suite, OWASP ZAP, Nuclei) have open redirect detection modules.

How to Prevent Open Redirects

1. Whitelist Allowed Redirect Destinations

The strongest defense. Only allow redirects to URLs on a predefined whitelist:

const ALLOWED_REDIRECTS = ['/dashboard', '/profile', '/settings'];

function safeRedirect(req, res) {
  const target = req.query.redirect;
  if (ALLOWED_REDIRECTS.includes(target)) {
    return res.redirect(target);
  }
  return res.redirect('/dashboard'); // default fallback
}

2. Restrict to Same-Origin Redirects

If you cannot whitelist specific paths, at minimum restrict redirects to your own domain:

function safeRedirect(req, res) {
  const target = req.query.redirect;

  try {
    const url = new URL(target, `https://${req.headers.host}`);
    if (url.origin !== `https://${req.headers.host}`) {
      return res.redirect('/dashboard');
    }
    return res.redirect(url.pathname);
  } catch {
    return res.redirect('/dashboard');
  }
}

3. Use Indirect References

Instead of passing the redirect URL directly, use an identifier that maps to a predefined URL on the server:

/login?redirect=dashboard     (maps to /dashboard on server)
/login?redirect=profile       (maps to /profile on server)
/login?redirect=evil.com      (no mapping found, redirect to default)

4. Add User Confirmation

If you must allow redirects to external URLs (e.g., a link shortener), show an interstitial page: "You are being redirected to [external-url]. Click to continue." This makes the redirect explicit and gives users a chance to recognize a phishing attempt.

Open Redirects and Redirect Tracing

When you trace a redirect chain and see a hop to an unexpected external domain, that is a red flag. It could indicate an open redirect being exploited, or it could be a legitimate third-party redirect. Either way, unexpected external hops in your redirect chains deserve investigation.

---

An open redirect turns your trusted domain into a weapon. Validate every redirect target, every time.