• Agents
  • Docs
  • Pricing
  • Blog
Log in
Get started

Security for apps built with AI. Paste a URL, get a report, fix what matters.

Product

  • How it works
  • What we find
  • Pricing
  • Agents
  • MCP Server
  • CLI
  • GitHub Action

Resources

  • Blog
  • Docs
  • FAQ
  • Glossary

Security

  • Supabase Security
  • Next.js Security
  • Lovable Security
  • Cursor Security
  • Bolt Security

Legal

  • Privacy Policy
  • Terms of Service
  • Cookie Policy
  • Imprint
© 2026 Flowpatrol. All rights reserved.
Home/Glossary/Open Redirect
CWE-601

Unvalidated Redirect (Open Redirect)

An open redirect occurs when an application accepts a user-controlled URL parameter and redirects the browser to it without validation. Attackers craft links that start at your trusted domain but land on a phishing page. It is classified under CWE-601 (URL Redirection to Untrusted Site) and is frequently chained with OAuth flows to steal tokens.

What is Open Redirect?

Your app has a login page at /auth/sign-in?next=/dashboard. After signing in, users land on /dashboard. Simple. But what happens when someone changes that to /auth/sign-in?next=https://evil.com? If your app blindly follows the next parameter, the user ends up on a phishing page — and the URL they clicked started on your domain.

That's an open redirect. The victim trusts your link because it starts with yourapp.com. Their browser shows your domain in the address bar right up until the redirect fires. By the time they land on the attacker's page, they're already entering their credentials.

Open redirects are CWE-601 and often dismissed as low-severity on their own. But they become critical when chained with OAuth flows. An attacker who controls the redirect URI can intercept authorization codes and steal access tokens — turning a "low" finding into a full account takeover.

How does Open Redirect work?

The pattern is simple: your app reads a URL from a query parameter, cookie, or form field, and passes it straight to a redirect function. No allowlist. No same-origin check. The browser follows wherever it's told.

Here's how this looks in a Next.js middleware or route handler:

Vulnerable — no validation on redirect target
// app/auth/callback/route.ts
import { redirect } from 'next/navigation';

export async function GET(req: Request) {
  const url = new URL(req.url);
  const next = url.searchParams.get('next') || '/';

  // Authenticate the user...
  await authenticateUser(req);

  // Problem: redirects to any URL the attacker provides.
  // /auth/callback?next=https://evil.com/steal-creds
  redirect(next);
}
Fixed — same-origin validation
// app/auth/callback/route.ts
import { redirect } from 'next/navigation';

export async function GET(req: Request) {
  const url = new URL(req.url);
  const next = url.searchParams.get('next') || '/';

  await authenticateUser(req);

  // Only allow relative paths (same origin)
  const isRelative = next.startsWith('/') && !next.startsWith('//');
  redirect(isRelative ? next : '/');
}

Why do AI tools generate Open Redirect vulnerabilities?

When you prompt an AI to build a login flow with a "redirect back to where the user was" feature, the model focuses on the redirect working — not on where it points. The happy path is all it optimizes for.

  • Redirect-after-login is a standard pattern. Every tutorial shows it. The AI generates the redirect parameter because it's expected — but skips the validation because tutorials skip it too.
  • URL validation is surprisingly tricky. Checking for same-origin isn't as simple as startsWith("/"). Attackers use //evil.com, /\evil.com, and URL-encoded tricks. AI models rarely handle all edge cases.
  • It feels harmless. The model doesn't flag redirects as dangerous because they don't touch the database or expose secrets directly. The risk only appears when you think like an attacker chaining multiple steps.

Open redirects appear in nearly every vibe-coded app that has a login flow. The AI adds the <code>next</code> parameter for good UX — then forgets to lock it down.

Common Open Redirect patterns

Post-login redirect

/auth/sign-in?next=https://evil.com — the most common vector. User logs in and lands on an attacker-controlled page.

OAuth callback manipulation

Changing the redirect_uri in an OAuth flow to steal authorization codes. Open redirects on the client app make this trivial.

Email link hijacking

Password reset or magic link emails that include a return URL parameter. Attacker modifies it before the victim clicks.

Double-encoded bypasses

Using %2F%2Fevil.com or /%09/evil.com to sneak past naive validation that only checks for http:// or https://.

How Flowpatrol detects Open Redirect

Flowpatrol actively probes your redirect endpoints the way a real attacker would — not just pattern-matching source code:

  1. 1Discovers redirect parameters by crawling your app and identifying query params like next, redirect, return_to, and callback.
  2. 2Injects external URLs including plain https://evil.com, protocol-relative //evil.com, and encoded bypass variants.
  3. 3Follows the redirect chain and checks whether the final destination leaves your origin. A 302 to an external domain is a confirmed finding.
  4. 4Reports the exact payload with the crafted URL, the redirect response, and a fix you can paste into your codebase.

Traditional scanners flag redirect parameters but can't tell if validation exists. Flowpatrol sends real requests and checks the actual behavior.

Related terms

Server-Side Request Forgery (SSRF)OAuth 2.0 Implementation Flaws (OAuth Misconfiguration)Cross-Site Scripting (XSS)

Check your app for open redirects.

Flowpatrol tests every redirect parameter with real payloads. Paste your URL and see what comes back.

Try it free