An open redirect looks harmless — your app just sends the user somewhere after login or logout. But if that "somewhere" comes from a URL parameter you don't validate, an attacker can use your trusted domain as a springboard to their phishing page.

How it works

Lots of apps redirect using a parameter — ?next=, ?redirect=, ?return_to=, ?url= — to send you back where you came from. If the app redirects to whatever's in that parameter:

    https://trusted-site.com/login?next=https://evil.example.com
# After login, the victim lands on evil.example.com

The bait is that the link starts on a domain the victim trusts. They click, you redirect, and they're on a pixel-perfect fake login page. Open redirects are also chained into OAuth token theft when the redirect URI isn't strictly validated.

How to fix it

  1. Don't redirect to raw user input. The default should be a fixed, server-decided destination.
  2. Prefer relative paths only. Accept /dashboard, reject anything containing a scheme (http://) or host.
  3. Allow-list external targets. If you truly need outbound redirects, validate against an explicit list of trusted domains.
  4. Validate OAuth redirect URIs exactly. Exact-match against registered URIs — no wildcards, no prefix matching.
  5. Watch for tricks.//evil.com, https:evil.com, and encoded variants bypass naive checks — validate the parsed result, not the raw string.
    // Safe: relative paths only
const next = url.searchParams.get('next') || '/'
const safe = next.startsWith('/') && !next.startsWith('//') ? next : '/'
return Response.redirect(new URL(safe, origin))

Find it in a scan

Open redirects are easy to introduce and easy to miss in review. Nurbak scans your deployed app for open redirects and the rest of the API security checklist, so a careless redirect parameter doesn't become a phishing vector with your name on it.

Related articles