Open Redirect Vulnerability: Exploitation, Examples, and Prevention Guide

The Problem With Open Redirects Is Context, Not Just Severity

Open redirects are a classic example of a bug that sounds minor when discussed in isolation. If all you picture is one page bouncing a user to another site, the risk seems limited.

That is not how attackers use them. They use them inside login flows, phishing chains, consent screens, and reputation-based trust decisions. The redirect itself is not the whole attack. It is the part that makes the rest of the attack believable.

An open redirect happens when an application redirects users to a destination controlled by user input without proper validation.

At first glance, it seems minor. In practice, open redirects are frequently chained into:

• phishing campaigns
• OAuth authorization code theft
• access control bypasses in legacy flows
• trust abuse on legitimate domains

---

The Classic Vulnerable Pattern

app.get('/redirect', (req, res) => {
  return res.redirect(req.query.next);
});

An attacker can send users to:

https://target.example/redirect?next=https://evil.example/login

The victim sees a legitimate domain first, clicks confidently, and lands on the attacker page.

---

Why Open Redirects Work So Well in Phishing

Users trust the beginning of a URL more than the end of a redirect chain. Security teams also sometimes allow trusted domains in email filters, chat tools, or browser reputation systems.

That makes open redirects valuable for attackers because they borrow your domain reputation.

---

Dangerous Validation Mistake 1: Checking Only the Prefix

Vulnerable Code

function isSafe(url) {
  return url.startsWith('https://target.example');
}

This is bypassable with inputs like:

• https://target.example.evil.example
• https://target.example@evil.example

Better Approach

const allowedOrigins = new Set(['https://target.example']);

function isSafeRedirect(candidate) {
  try {
    const parsed = new URL(candidate, 'https://target.example');
    return allowedOrigins.has(parsed.origin);
  } catch {
    return false;
  }
}

---

Dangerous Validation Mistake 2: Trusting Relative-Looking Inputs

These often bypass weak filters:

• //evil.example
• /\evil.example
• encoded or double-encoded variants

Safer Strategy

Only allow:

• exact internal paths like /dashboard
• pre-registered internal destinations
• explicit allowlisted full URLs when absolutely necessary

---

Dangerous Validation Mistake 3: Weak OAuth redirect_uri Matching

Many serious incidents begin here. If an authorization server validates only the domain and not the exact callback URL, attackers can steal authorization codes or tokens.

Bad Policy

• Any path under https://app.example.com
• Wildcards for callback URLs
• Partial string matching on redirect URIs

Safer Policy

• Register exact callback URLs per client
• Match scheme, host, port, and path exactly
• Do not allow wildcards for sensitive OAuth clients

---

Secure Redirect Pattern in Next.js

import { NextRequest, NextResponse } from 'next/server';

const allowedPaths = new Set([
  '/dashboard',
  '/settings',
  '/billing',
]);

export async function GET(request: NextRequest) {
  const next = request.nextUrl.searchParams.get('next') || '/dashboard';

  if (!allowedPaths.has(next)) {
    return NextResponse.redirect(new URL('/dashboard', request.url));
  }

  return NextResponse.redirect(new URL(next, request.url));
}

This is safer because it validates against a fixed list of relative paths.

---

How to Test for Open Redirects

1. Parameter Discovery

Look for parameters like:

• next
• returnTo
• redirect
• redirect_uri
• continue
• url

2. Input Probes

Try:

• https://evil.example
• //evil.example
• encoded variants
• same-domain userinfo tricks

3. OAuth Flow Review

Check authorization servers, login flows, logout flows, and SSO return URLs.

---

Open Redirect Hardening Checklist

• Prefer relative internal paths over external URLs
• Validate against exact allowlists
• Normalize and parse URLs before validation
• Block protocol-relative URLs like //evil.example
• Match OAuth redirect_uri values exactly
• Review login, logout, and post-auth flows first

Final Takeaway

The right question with open redirects is not "can this page send someone elsewhere?" It is "what trust or identity flow does this redirect sit inside?" Once you ask that, the risk becomes easier to evaluate. In most applications, the safest answer is still the boring one: keep redirects internal unless you have a strict, reviewed reason not to.