Open Redirect Vulnerability
Open redirect vulnerabilities occur when an application redirects users to a URL supplied in a parameter without validating the destination. Attackers can abuse this to redirect victims to phishing or malware sites. This guide explains how to detect open redirects, why they matter, and how to fix them.
What Is an Open Redirect?
An open redirect happens when a redirect parameter (e.g. url=, next=, return=, redirect=, goto=, destination=) accepts any URL and the application redirects the user there without validation. The application trusts user-supplied input as a redirect target. Attackers craft links that appear to go to your domain but silently redirect to phishing or malware sites. Because the initial URL shows your trusted domain, victims are more likely to click.
Open redirects are common in login flows, logout handlers, and "return to" links. Developers often add redirect parameters for convenience so users land on the right page after authentication. Without validation, any external URL can be used. The vulnerability is sometimes considered low severity because it does not directly expose data, but it enables phishing and can amplify social engineering attacks.
Risks
- Phishing: Victims trust your domain before redirect; attackers harvest credentials on fake login pages
- OAuth abuse: Redirect URIs in OAuth can leak authorization codes or tokens to attacker-controlled domains
- Malware: Redirect to drive-by download or exploit kit pages
- SEO spam: Redirect chains used to manipulate search rankings
Common Redirect Parameters
Redirect parameters go by many names. When testing or auditing, look for url, next, return, redirect, goto, destination, returnUrl, return_to, redirect_uri, callback, continue, and similar variants. Check both query strings and POST bodies. OAuth and OpenID Connect use redirect_uri; ensure it is validated against a strict allowlist.
https://example.com/login?redirect=https://evil.com
https://example.com/logout?return=https://phish.com
https://example.com/auth?redirect_uri=https://attacker.com/callbackHow to Detect Open Redirect
Test redirect parameters by supplying external URLs. If the application redirects to the supplied URL (or follows a chain that ends there), it is vulnerable. Use a domain you control for testing; never use real malicious domains. Vulnify's redirect chain checker and full website scanner test for open redirects across discovered parameters.
Manual testing: identify pages that perform redirects, extract the parameter name, and replace the value with an external URL. Check the response: a 302 or 301 to your test URL confirms vulnerability. Some applications use JavaScript redirects instead of HTTP; inspect the Location header and any client-side redirect logic.
Detection Checklist
- Identify all redirect parameters (url, next, return, etc.)
- Test with absolute external URLs (https://your-test-domain.com)
- Check for bypass techniques (double encoding, relative paths with //)
- Run Vulnify redirect chain checker or full website scanner
How to Fix Open Redirect
Validate redirect URLs against an allowlist of relative paths or trusted domains. Reject absolute URLs to external domains. Use a mapping of redirect tokens to URLs instead of accepting raw URLs. For example, store allowed destinations in a server-side map and accept only a token like ?next=checkout; resolve the token to /checkout on the server.
If you must support external redirects, maintain a strict allowlist of domains. Do not use blocklists; attackers can use subdomains or new domains. Validate the scheme (https only), host, and path. Reject URLs with userinfo, fragments, or unusual schemes. Log redirect attempts for security monitoring.
Fix Checklist
- Allow only relative paths (e.g. /dashboard) or trusted domain allowlist
- Reject absolute URLs to external domains
- Use token-based redirect mapping when possible
- Validate redirect_uri in OAuth against registered callback URLs
Frequently Asked Questions
How do I test for open redirect?
Use Vulnify's redirect chain checker or full website scanner. Supply external URLs in redirect parameters and check if the app redirects. Use a domain you control for safe testing.
Is open redirect critical?
It is often rated medium. It does not directly expose data but enables phishing and can leak OAuth tokens. Fix it as part of a defense-in-depth strategy.
Can encoding bypass redirect validation?
Sometimes. Double encoding, Unicode, or protocol-relative URLs (//evil.com) can bypass weak validation. Use strict parsing and reject unexpected formats.