A redirect attack — more precisely an open redirect vulnerability — happens when a web application accepts a URL as a parameter and redirects users to it without validating that the destination is safe, letting an attacker craft a link that starts on a trusted domain and ends on an attacker-controlled site. On its own, an open redirect looks almost too simple to matter: no data is stolen, no code executes, the victim is just sent somewhere else. But that "somewhere else" being reachable through a link that visibly begins with a trusted, familiar domain is exactly what makes open redirects a persistently useful tool for phishing campaigns, and in some architectures, for stealing OAuth tokens outright.
What is an open redirect attack, exactly?
An open redirect attack exploits a URL parameter — commonly named something like ?redirect=, ?url=, ?next=, or ?returnTo= — that a web application uses to send users somewhere after an action, such as after logging in or clicking through a marketing link. If the application redirects to whatever value that parameter contains without checking it against an allow-list of expected destinations, an attacker can construct a URL like https://trusted-site.com/login?redirect=https://malicious-site.example and share that link. A victim who clicks it sees a familiar, legitimate domain in the link and in the address bar right up until the redirect fires, which is precisely the trust signal phishing relies on — most people are trained to check the domain in a link before clicking, and an open redirect defeats that check by putting a real, trusted domain at the front of the URL.
Why do security teams sometimes underrate open redirect vulnerabilities?
Because in isolation, an open redirect doesn't directly compromise data or execute code, it's commonly scored at low or informational severity by automated scanners and sometimes deprioritized in bug bounty triage relative to injection or authentication flaws. That framing misses how open redirects get used in practice: as one link in a chain, not the whole attack. A phishing email that links directly to malicious-site.example gets flagged by email security filters and browser reputation systems fairly reliably; a phishing email that links to trusted-bank.com/redirect?url=malicious-site.example often sails through the same filters, because the visible, reputationally-scored domain in the link is the trusted one. The redirect is the delivery mechanism, and the actual damage — credential harvesting on a spoofed login page, malware delivery — happens after the hop.
How does an open redirect combine with OAuth to become more serious?
This is where an open redirect stops being purely a phishing helper and becomes a genuine data-theft vector: OAuth and OpenID Connect flows pass an authorization code or, in older/misconfigured implicit-flow implementations, an access token directly in the redirect URL back to a registered "redirect_uri." If an application's OAuth implementation validates the redirect URI too loosely — for instance, checking only that it starts with the expected domain rather than matching the full path exactly — and that domain also hosts an open redirect elsewhere in the application, an attacker can potentially chain the two: get the OAuth provider to send the authorization code or token to the legitimate redirect URI, which the open redirect then forwards on to an attacker-controlled endpoint, exposing the token or code and effectively hijacking the login session. This is precisely why the OAuth 2.0 security best-practice guidance is emphatic about exact-match redirect URI validation rather than prefix or substring matching — a loosely validated redirect URI turns any open redirect elsewhere on the same domain into a session-hijacking primitive.
How do you actually prevent open redirect vulnerabilities?
The most reliable fix is avoiding user-controlled redirect targets entirely wherever possible — if the set of legitimate post-action destinations is small and known (a dashboard, a settings page, a handful of marketing landing pages), use an internal reference or index into a server-side allow-list rather than accepting a raw URL from the client at all. Where a raw destination genuinely must be accepted — for example, "return to whatever page the user was on before login," which could be nearly anywhere in the app — validate that it's a relative path within your own application (rejecting anything starting with http://, https://, //, or containing an @ sign that could smuggle a different host past a naive check) rather than trying to blocklist known-bad patterns, since blocklists for URL parsing tend to have bypasses. For OAuth and OIDC implementations specifically, enforce exact-match redirect URI validation, registered in advance, with no wildcard or prefix matching permitted.
How Safeguard Helps
Safeguard's dynamic application security testing exercises live application endpoints for exactly this class of issue, flagging redirect parameters that accept arbitrary external destinations without allow-list validation, so the finding surfaces from actual request/response behavior rather than a purely theoretical code-pattern match. See the SAST/DAST product page for how static and dynamic scanning combine to catch both the vulnerable code pattern and its live, exploitable behavior.
FAQ
Is an open redirect the same thing as a CSRF vulnerability?
No — they're different flaw classes. Open redirects abuse an application's own redirect logic to send users to an external destination; CSRF abuses a victim's authenticated session to make an unwanted request on their behalf. They're sometimes combined in attack chains but are distinct vulnerabilities.
Why do bug bounty programs sometimes pay very little for open redirects?
Because in isolation an open redirect rarely leads to direct data exposure or account compromise, many programs score it as low severity unless the researcher demonstrates a realistic exploitation chain — such as combining it with a loosely validated OAuth redirect URI to show actual token or session exposure.
Can an open redirect be fixed just by blocklisting known malicious domains?
No — blocklisting specific bad domains doesn't scale and misses new attacker-controlled domains entirely. The reliable fix is allow-listing expected destinations or restricting redirects to relative, in-application paths rather than trying to enumerate bad external URLs.
Does HTTPS prevent open redirect attacks?
No — HTTPS protects the confidentiality and integrity of the connection itself, but it has no bearing on whether an application validates a redirect destination. An open redirect works identically whether the vulnerable site and the attacker's destination are both served over HTTPS.