Open redirect vulnerabilities let an attacker take a trusted domain's URL and use it to bounce a victim to an attacker-controlled site — no code injection, no authentication bypass, just a parameter the application forgot to validate. A link that starts with https://yourbank.com/login?redirect= looks safe to a user and to most email filters, but if the redirect target isn't checked against an allowlist, that same link can end at https://yourbank-secure.attacker.io. Tracked as CWE-601 and typically scored 4.3–6.1 (Medium) under CVSS 3.1, open redirects rarely lead to direct data theft on their own, which is why they get deprioritized in vulnerability backlogs. But they're consistently one of the highest-yield building blocks in phishing kits, OAuth token theft chains, and SSRF pivots, precisely because they weaponize a domain's reputation instead of attacking it directly.
What is an open redirect vulnerability?
An open redirect vulnerability is a flaw where a web application redirects users to a URL supplied through user input — a query parameter, a form field, or a header — without verifying that the destination is safe or belongs to the application's own domain. The classic pattern shows up in login flows, logout handlers, and "continue to" links: example.com/redirect?url=https://attacker-site.com. The server reads the url parameter and issues an HTTP 302 or 303 response pointing the browser there, no questions asked. This is formally cataloged as CWE-601 ("URL Redirection to Untrusted Site") and was significant enough to earn its own entry, A10, on the OWASP Top 10 2013 list under the name "Unvalidated Redirects and Forwards." It was folded into broader access-control categories in later OWASP revisions, not because the bug disappeared, but because it's now understood as one symptom of a larger input-validation failure pattern rather than a standalone top-tier risk.
How does an open redirect attack actually work?
An open redirect attack works by exploiting the gap between what a URL's hostname says and where the URL's redirect parameter actually sends the browser. Take a phishing email containing https://accounts.example.com/oauth/authorize?redirect_uri=https://evil.example. The visible, clickable domain is accounts.example.com — a real, trusted, TLS-certified site that passes every automated URL reputation check a secure email gateway runs. The user clicks, the legitimate server briefly loads, and then a 302 response silently forwards the browser to evil.example, which hosts a pixel-perfect clone of the login page. Because the initial request went to a legitimate domain, tools that check "is this URL's registered domain malicious" — which is how most spam filters and antivirus URL scanners operate — see a clean pass. The attack chain typically runs three steps: craft the redirect URL, deliver it via email/SMS/ad, and harvest credentials or session tokens on the spoofed landing page once the victim lands there.
Why do security teams underrate open redirects if they're so useful for phishing?
Security teams underrate open redirects because a lone open redirect, in isolation, doesn't compromise data, so it scores in the medium range and gets triaged behind SQL injection or RCE findings. A CVSS 6.1 score reflects that the bug requires user interaction and doesn't affect confidentiality or integrity of the vulnerable server itself — the server's data is never at risk. What that scoring model misses is chaining value. Open redirects are routinely combined with OAuth 2.0 implicit-grant flows, where a compromised redirect_uri can leak access tokens directly into an attacker's server logs via the URL fragment. They're also used to bypass egress and SSRF filters that only validate the first hop of a request, and to defeat email security gateways that only inspect the displayed domain, not the final destination after redirects resolve. Check Point researchers documented this exact pattern in Zoom's vanity-URL redirect handling in 2019, showing how a trusted zoom.us link could be walked to a spoofed meeting-join page. The vulnerability class is low severity per host; it is high severity per campaign.
What are real examples of open redirect vulnerabilities being exploited?
Real-world open redirect exploitation almost always shows up as a phishing infrastructure component rather than a headline breach on its own. Google's own google.com/url redirector was abused for over a decade in spam and phishing campaigns before Google restricted it in 2018 to require signed, first-party-only redirect targets. American Express customers were targeted in a 2017 phishing wave that used an open redirect on americanexpress.com itself to route victims to credential-harvesting pages, making the phishing link pass every "hover over the link" sanity check a trained employee would perform. More recently, Microsoft's login infrastructure (login.microsoftonline.com) has repeatedly appeared in phishing campaign writeups from 2021 through 2023 because attackers embed open-redirect parameters in otherwise-legitimate Microsoft 365 authentication URLs to bypass secure email gateway domain reputation checks. In each case the pattern is identical: a Fortune 500 domain's own redirect handler becomes the delivery mechanism for credential theft against that same company's users or customers.
How do you detect open redirect vulnerabilities in your codebase?
You detect open redirect vulnerabilities by tracing every code path where a variable derived from request input reaches a redirect-issuing function — Response.Redirect, HttpResponseRedirect, res.redirect(), header("Location: ..."), or framework equivalents — without passing through a validation step first. Static analysis (SAST) tools flag this as a tainted-data-flow finding: source is request.getParameter("url") or similar, sink is the redirect call, and no sanitizing function sits between them. The harder problem in real codebases isn't finding the pattern — grep for redirect( gets you 80% of the way — it's determining which of the dozens or hundreds of matches are actually reachable from an unauthenticated, internet-facing route versus buried behind an admin-only, already-authenticated internal tool. A 50,000-line monolith with 40 redirect call sites might have only 2 that are internet-reachable without a session token; treating all 40 as equally urgent wastes remediation hours and burns developer trust in the scanner.
How do you fix and prevent open redirect vulnerabilities?
You fix open redirect vulnerabilities by refusing to redirect to any URL that isn't on a server-side allowlist, and you prevent them by never trusting client-supplied absolute URLs as redirect targets in the first place. The most reliable pattern is to store redirect destinations as relative paths only (/dashboard, not https://example.com/dashboard) and reject any target string containing a scheme (http://, https://) or a double-slash prefix (//attacker.com), which browsers treat as protocol-relative and will happily follow. Where an application genuinely needs to redirect to external partner domains — SSO callbacks, payment processor returns — the fix is a strict allowlist of exact hostnames checked against a parsed URL object, never a substring or startsWith() check against the raw string, since example.com.attacker.io and notexample.com both pass naive substring tests. For OAuth flows specifically, redirect_uri values must be registered in advance and matched exactly, per RFC 6749 Section 3.1.2, rather than validated with pattern matching at request time.
How Safeguard Helps
Safeguard's reachability analysis traces exactly which redirect call sites in your codebase are actually invoked from unauthenticated, internet-facing entry points, so a 40-instance open redirect finding gets triaged down to the 2 or 3 that represent real phishing-enablement risk instead of 40 equally-weighted tickets. Griffin AI reviews the surrounding code path — including how the redirect target is sourced and whether an allowlist check already exists nearby — to cut false positives that plague generic taint-tracking SAST rules. Safeguard generates and ingests SBOMs so you can see whether the vulnerable redirect logic lives in first-party code or a third-party auth/SSO library you depend on, and where it's a straightforward fix, Safeguard opens an auto-fix PR that swaps unchecked redirect calls for allowlist-validated ones, so the fix ships as a reviewable diff rather than a backlog item that sits behind higher-CVSS-score findings indefinitely.