Open Redirect
detect, understand, remediate
Open redirect vulnerabilities allow attackers to redirect users from a trusted domain to a malicious site, enabling phishing attacks that leverage the trust of the vulnerable domain.
No credit card required. Free plan available forever.
What is an open redirect?
An open redirect vulnerability occurs when a web application accepts user-controlled input to determine the destination of a redirect and forwards the user to an external, potentially malicious URL without proper validation. Because the redirect originates from a trusted domain, victims are more likely to trust the destination.
Attackers exploit open redirects primarily for phishing, crafting URLs that appear to belong to a legitimate site but ultimately redirect to credential-harvesting pages. The trusted domain in the URL lulls users into a false sense of security, making phishing campaigns significantly more effective.
Open redirects can also be chained with other vulnerabilities. They are commonly used to bypass SSRF filters, circumvent OAuth redirect URI validation, steal authentication tokens, or escalate the impact of cross-site scripting (XSS) attacks by redirecting users after exploitation.
How it works
Find redirect parameter
Attacker identifies a URL parameter used for redirection, commonly named redirect, url, next, return, continue, or dest.
Inject malicious URL
The attacker replaces the redirect parameter value with a URL pointing to a phishing site they control, e.g. ?redirect=https://evil.com.
Victim clicks trusted link
The phishing link appears to come from the legitimate domain, so the victim clicks it without suspicion, often delivered via email or social media.
Redirected to attacker site
The application blindly redirects the victim to the malicious URL, where credentials or session tokens are harvested.
Common causes
Unvalidated redirect parameters
Using user-supplied values directly in HTTP Location headers or meta refresh tags without checking whether the destination is an allowed URL.
User input in Location header
Setting the HTTP Location response header based on query parameters, form fields, or path segments without validation or sanitisation.
Redirect-after-login without validation
Post-authentication redirect patterns that store the target URL in a query parameter (e.g. /login?next=/dashboard) without verifying the destination.
Insufficient URL validation
Checking only the beginning of the URL (e.g. starts with /) but failing to account for protocol-relative URLs (//evil.com) or domain prefix tricks.
How to detect it
Automated detection
- SecPortal's authenticated scanner identifies redirect parameters and tests whether external URLs are followed without validation
- Code scanning detects patterns where user input flows into redirect functions or Location header assignments
- Domain scanning identifies endpoints that return 3xx responses with user-controllable Location headers
Manual testing
- Replace redirect parameter values with external URLs and check if the server issues a 302/301 redirect to the attacker-controlled destination
- Test bypass techniques: protocol-relative URLs (//evil.com), URL encoding, backslash tricks (/\evil.com), and domain confusion (trusted.com.evil.com)
- Check login, logout, and OAuth callback flows for redirect parameters that can be manipulated
How to fix it
Avoid user-controlled redirects
The most effective fix is to eliminate redirects based on user input entirely. Use server-side logic to determine redirect destinations.
Use an allow-list of destinations
If redirects are necessary, maintain a strict allow-list of permitted URLs or domains and reject any destination not on the list.
Validate against the same domain
Parse the redirect URL and verify that the hostname matches your application's domain. Be careful to handle protocol-relative URLs and URL parsing edge cases.
Use indirect reference maps
Instead of passing URLs as parameters, use numeric or opaque identifiers that map to allowed destinations on the server side (e.g. ?dest=1 maps to /dashboard).
Compliance impact
Detect open redirects automatically
SecPortal tests for open redirects with encoding bypasses, null bytes, and credential injection payloads. Start free.
No credit card required. Free plan available forever.