Open Redirect: How Attackers Hijack Your Login Flow

What is open redirect?

Open redirect (CWE-601) happens when your application blindly redirects users to any URL specified in a request parameter. Users see your familiar domain and trust the link, but after clicking, they end up on an attacker's phishing site.

Think of it like a receptionist at a trusted company who gives visitors directions to wherever someone asks - including to a scam office down the street. The receptionist (your app) doesn't verify the destination, just redirects.

Why is this dangerous? Users trust your domain. They see the SSL lock, recognize the URL, and click. By the time they realize they're on a fake site that looks just like yours, they've already entered their credentials.

Why open redirects are dangerous

Where AI tools create open redirects

When you ask AI tools to "redirect after login" or "add a return URL," they generate the simplest working code without validation. This is a classic vibe coding trap - the code works perfectly until an attacker finds it.

Common vibe coded patterns that create open redirects:

• Login flows - "Return to original page after login"
• OAuth callbacks - "Redirect after successful authentication"
• Action completions - "Redirect after form submission"
• Email links - "Track clicks and redirect to destination"
• Short URLs - "Create redirect service"

Common open redirect patterns

Attackers have various techniques to exploit and bypass weak validation:

For detailed exploitation techniques, see the PortSwigger Open Redirect Guide.

Vulnerable code examples

Pattern 1: Vulnerable Return URL (AI Default)

// AI generates this for "return after login"
app.get('/login', (req, res) => {
  const returnUrl = req.query.returnUrl || '/'
  // ... authenticate user ...
  res.redirect(returnUrl) // DANGEROUS!
})

// Attacker: /login?returnUrl=https://evil-phishing-site.com
// User sees your trusted login, then lands on phishing page

Any URL accepted as redirect target. The attacker crafts links that look legitimate but redirect to phishing.

Pattern 2: Vulnerable OAuth Callback

// OAuth callback without validation
app.get('/auth/callback', async (req, res) => {
  const { code, state } = req.query
  // ... exchange code for token ...

  const redirectTo = req.query.redirect || '/dashboard'
  res.redirect(redirectTo) // DANGEROUS!
})

// Attacker: /auth/callback?code=xxx&redirect=https://evil.com
// Token ends up exposed in attacker-controlled destination

OAuth flows are high-value targets. Without validation, attackers can steal tokens by controlling the redirect.

How to fix open redirects

Secure Pattern: Path Allowlist (Recommended)

// Validate against allowlist of paths
const ALLOWED_REDIRECTS = ['/', '/dashboard', '/profile', '/settings']

function isValidRedirect(url) {
  // Must be a string
  if (!url || typeof url !== 'string') return false

  // Must start with / (relative path)
  if (!url.startsWith('/')) return false

  // Must NOT be protocol-relative (//evil.com)
  if (url.startsWith('//')) return false

  // Remove query string for comparison
  const path = url.split('?')[0]

  // Check against allowlist
  return ALLOWED_REDIRECTS.some(allowed =>
    path === allowed || path.startsWith(allowed + '/')
  )
}

app.get('/login', (req, res) => {
  const returnUrl = req.query.returnUrl || '/'

  if (!isValidRedirect(returnUrl)) {
    return res.redirect('/') // Default to safe page
  }

  // ... authenticate ...
  res.redirect(returnUrl)
})

Only allow specific, known paths. Reject external URLs, protocol-relative URLs, and unexpected paths.

Secure Pattern: Domain Validation

// Validate URL is on trusted domain
const TRUSTED_DOMAINS = ['myapp.com', 'app.myapp.com']

function isValidRedirectUrl(urlString) {
  try {
    // Parse with base URL to handle relative paths
    const url = new URL(urlString, 'https://myapp.com')

    // Must be trusted domain
    if (!TRUSTED_DOMAINS.includes(url.hostname)) {
      return false
    }

    // Block dangerous protocols
    if (!['http:', 'https:'].includes(url.protocol)) {
      return false
    }

    return true
  } catch {
    return false
  }
}

Parse URLs properly using the URL constructor. Validate hostname and protocol explicitly.

Most Secure: Mapping Approach

// Map IDs to URLs instead of accepting URLs directly
const REDIRECT_MAP = {
  'dashboard': '/dashboard',
  'profile': '/profile',
  'settings': '/settings',
  'home': '/',
}

app.get('/goto', (req, res) => {
  const target = req.query.target
  const redirectUrl = REDIRECT_MAP[target] || '/'
  res.redirect(redirectUrl)
})

// Usage: /goto?target=dashboard
// Attacker cannot inject arbitrary URLs

Never accept URLs directly. Map safe identifiers to hardcoded URLs. Impossible to exploit.

Key Security Points

• Allowlist, don't blocklist - specify exactly what's allowed
• Check for // - protocol-relative URLs bypass http checks
• Block javascript: and data: - can execute code
• Use URL parser - don't regex match URLs manually
• Consider mapping - IDs are more secure than URLs

Related Security Topics

External Resources

• CWE-601: Open Redirect - Official vulnerability definition
• OWASP Redirect Cheat Sheet - Prevention recommendations
• PortSwigger Open Redirect - Detection and exploitation
• Snyk Open Redirect - Practical examples