Open Redirect

An open redirect is a flaw where your app sends users to a URL taken from user-controlled input (like ?url= or ?next=) without validating it, letting attackers redirect visitors from your trusted domain to a malicious site.

What is an open redirect?

Many sites send users to a destination URL passed in a query parameter. You see it after login (?next=/dashboard), in tracking links, logout flows, and "continue" buttons. The parameter names vary: ?url=, ?next=, ?return=, ?redirect=, ?dest=, ?continue=.

The problem appears when the application reads that value and issues a redirect (an HTTP 302/Location header or a client-side window.location assignment) without checking where it points. If the app accepts any URL, an attacker can supply an external address and your domain will happily forward the victim to it.

This was tracked by OWASP as "Unvalidated Redirects and Forwards." It's a low-complexity bug that's easy to miss because the redirect feature itself works exactly as designed for legitimate paths.

Why it's a risk / how it's exploited

The danger is trust. The link the victim clicks starts with your domain, so it passes the eyeball test, email filters, and link-preview checks.

A typical phishing scenario:

https://yoursite.com/login?next=https://yoursite-com.attacker.com/login

The victim sees yoursite.com, clicks, authenticates (or is silently bounced), and lands on a pixel-perfect fake login on the attacker's host. Credentials go straight to the attacker.

Open redirects also enable:

• OAuth / token theft — if a redirect parameter is reused as (or smuggled into) an OAuth redirect_uri, an authorization code or access token can be delivered to an attacker-controlled origin.
• Security-filter bypass — allowlists, SSRF guards, and WAF rules that trust requests "to our own domain" can be tricked into chaining through your redirect to reach an external or internal target.
• Malware delivery — the same trusted-link technique drives downloads from your domain into a malicious payload host.

No XSS or code execution is needed; the redirect is the whole exploit.

How to detect it

Find every endpoint that redirects based on a parameter, then test whether it will send you off-site. Use curl and watch the Location header without following it:

curl -sI "https://yoursite.com/login?next=https://example.com/" | grep -i location

If the response is something like Location: https://example.com/, the redirect is open. Try the common variants and known bypasses attackers use:

?next=//example.com            # protocol-relative, often slips past naive checks
?next=https:example.com        # missing slashes
?next=/\example.com            # backslash trick
?next=https://yoursite.com.example.com  # your domain as a subdomain of theirs

A safe app should reject these, strip them, or send you back to a same-site default. A vulnerability scan will crawl your redirect parameters and flag these automatically across the whole app — useful when you have many endpoints and login/logout flows to cover. See how to scan a website for vulnerabilities for the workflow.

How to fix it

The rule: never redirect to a raw user-supplied URL. Pick one of these, strongest first.

1. Allowlist the targets. Map an opaque key to a fixed URL server-side; the user never controls the destination string.

2. Accept only relative, same-site paths. Reject anything with a scheme or host. Reject protocol-relative (//) and backslash forms too.

// Node example
function safeNext(next) {
  // must start with a single "/" and not "//" or "/\"
  if (typeof next === 'string' && /^\/(?![/\\])/.test(next)) return next;
  return '/dashboard'; // safe default
}

3. If you must allow external hosts, validate against an explicit host allowlist by parsing the URL and comparing hostname exactly (not startsWith / includes, which the bypasses above defeat).

For server-issued redirects, you can also block off-site Location values at the edge. Nginx example that only redirects to local paths:

location = /go {
    if ($arg_next !~ "^/(?![/\\])") { return 400; }
    return 302 $arg_next;
}

Always fail closed: an invalid or unrecognized target should fall back to a known internal page, never to the attacker's input.

FAQ

Is an open redirect "just" low severity? On its own it's often rated low, but it's a force multiplier for phishing and a building block for OAuth token theft and filter bypass, so treat it as a real finding.

Does HTTPS or a WAF stop it? No. The redirect is a legitimate feature being abused; TLS and generic WAF rules don't know the destination is malicious.

---

Auditing redirect parameters by hand across a large app is slow. Run a full scan with Exploita to find unvalidated redirects and the rest of your web attack surface in one pass.