Open Redirect
debt(d5/e3/b3/t7)
Closest to 'specialist tool catches it' (d5). The detection_hints list semgrep and psalm — both specialist SAST tools — as the automated detection path. The code_pattern shows these tools target specific taint flows (e.g. header('Location: '.$_GET[)), which means common linters won't catch it by default, but a configured semgrep ruleset or psalm taint analysis will. Not visible at compile time and not caught by default linters, so d5 is the right anchor.
Closest to 'simple parameterised fix' (e3). The quick_fix says to use an allowlist of permitted destinations or internal path-only redirects — this is a contained change at the redirect call site(s), typically replacing one pattern with a safer validated alternative. It doesn't require a cross-cutting refactor, but it's more than a single one-line swap if multiple redirect points exist, hence e3 rather than e1.
Closest to 'localised tax' (b3). The applies_to scope is web context only, and the fix is concentrated at redirect call sites within individual request-handling code. It doesn't shape the overall architecture or impose a persistent tax on every future feature, but each developer touching URL-handling code must be aware of the pattern. b3 is appropriate — one component pays, the rest of the codebase is largely unaffected.
Closest to 'serious trap' (t7). The misconception field explicitly states that developers treat open redirects as low severity because 'they just redirect users,' missing that they are routinely chained into phishing, OAuth bypass, and SSRF attacks. The common_mistakes reinforce this: strpos() domain validation and protocol-relative URLs both appear safe but are trivially bypassed. This contradicts how developers typically reason about redirect severity, warranting t7.
Also Known As
TL;DR
Explanation
An open redirect lets an attacker craft a URL on your trusted domain that immediately redirects to a malicious site. Because the initial URL appears legitimate (e.g. yourbank.com/login?next=evil.com), victims are more likely to click it. Attackers use open redirects in phishing campaigns and OAuth token theft. Mitigation: validate redirect targets against an explicit allowlist of permitted paths, or restrict to relative URLs only.
How It's Exploited
# After login, user is silently redirected to phishing site
Common Misconception
Why It Matters
Common Mistakes
- Using $_GET['redirect'] or $_GET['next'] directly in header('Location: ...') without validation.
- Validating that the URL starts with your domain using strpos() — trivially bypassed with your-domain.evil.com.
- Allowing protocol-relative URLs (//evil.com) which browsers interpret as full redirects.
- Forgetting that JavaScript redirects (window.location) are equally exploitable if fed from user input.
Code Examples
// Redirects to any URL the user provides
$url = $_GET['next'];
header('Location: ' . $url);// Allowlist approach
$allowed = ['/dashboard', '/profile', '/orders'];
$next = $_GET['next'] ?? '/dashboard';
$target = in_array($next, $allowed, true) ? $next : '/dashboard';
header('Location: ' . $target);
// Or validate it's the same host
$parsed = parse_url($next);
if (!empty($parsed['host'])) { $next = '/dashboard'; } // reject absolute URLs