Open Redirect
An open redirect is a vulnerability where an application accepts a user-controlled URL parameter and redirects the browser to it without validation, enabling attackers to redirect users to malicious sites using a trusted domain.
Understanding Open Redirect
Open redirects occur when a web application takes a URL from a query parameter (commonly named redirect, url, next, or return_to) and issues an HTTP redirect to that URL without checking whether the destination is trusted. Attackers exploit this by crafting links that appear to point to the legitimate domain but redirect to a phishing page.
For example, https://trusted-bank.com/login?redirect=https://evil-bank.com looks like it goes to the bank's login page, and the trusted domain passes most users' visual inspection. After authenticating on the real login page, the user is silently redirected to the attacker's site, which can mimic the bank's interface and capture additional credentials or financial information.
Open redirects are classified as medium severity on their own, but they become high severity when used as a component in attack chains. They are frequently used to enhance phishing campaigns by leveraging the victim's trust in the legitimate domain, bypass URL filters and security controls that allowlist the trusted domain, and steal OAuth tokens by redirecting authorization flows to attacker-controlled endpoints.
Prevention requires validating redirect targets against an allowlist of permitted domains, using relative URLs instead of absolute URLs for internal redirects, avoiding user-controlled redirect parameters entirely where possible, and if a redirect parameter is necessary, using an indirect reference (like a numeric ID mapping to a known URL) rather than accepting raw URLs.
Why This Matters for Vibe-Coded Apps
AI-generated login flows frequently include a redirect parameter for "return to the page you were trying to visit after login." The AI typically implements this as a simple redirect to whatever URL is in the parameter without any validation. This is a textbook open redirect, and it appears in the authentication flows of many vibe-coded applications.
When an AI generates login or OAuth callback handling, check whether the redirect URL is validated. The safest approach is to only accept relative paths (starting with /) and reject any absolute URLs. If you must accept absolute URLs, validate them against a strict allowlist of your own domains.
Real-World Examples
Google Open Redirect (Historical)
Google's various services have had multiple open redirect vulnerabilities over the years, where google.com URLs could redirect to arbitrary destinations. These were heavily exploited in phishing campaigns because spam filters and users both trust Google URLs.
OAuth Token Theft via Open Redirect
Attackers combined OAuth flows with open redirects to steal authorization codes. By registering a client with a redirect_uri pointing to a page with an open redirect, the attacker could chain the redirect to capture OAuth tokens sent to the legitimate callback URL.
US Government Open Redirect Phishing
Open redirects on .gov domains were used in targeted phishing campaigns against government employees. Because .gov URLs pass most email security filters and employee training (users are told to trust .gov domains), these redirects were highly effective attack vectors.
Frequently Asked Questions
Is an open redirect really a security vulnerability?
Yes, though its severity depends on context. As a standalone issue, it is medium severity because it requires user interaction (clicking a link). However, open redirects become high severity when used in attack chains: stealing OAuth tokens, enhancing phishing campaigns with trusted domain URLs, bypassing URL-based security controls, or redirecting post-authentication flows. Bug bounty programs consistently accept open redirect reports, though payouts vary.
How do I fix an open redirect?
The best fix is to avoid user-controlled redirect URLs entirely. Use a session or database to store the intended destination and retrieve it server-side. If you must accept a redirect parameter, validate it against an allowlist of trusted domains, only accept relative paths (and verify they do not start with // which would be interpreted as a protocol-relative URL), or use an indirect reference map where the parameter is a key that looks up a predetermined URL.
Can open redirects bypass URL filters?
Yes. Many security systems (email filters, web application firewalls, browser safe browsing lists) check the domain of a URL to determine if it is safe. An open redirect on a trusted domain passes these checks because the initial URL points to a known-safe domain. The redirect to the malicious destination happens after the filter has already approved the URL. This makes open redirects on popular domains particularly valuable for attackers.
What about JavaScript-based redirects?
JavaScript redirects (window.location = userInput) are equally vulnerable. The fix is the same: validate the destination before redirecting. Additionally, client-side redirects can sometimes be exploited even when server-side redirects are protected. Always validate redirect targets on the server side, even if the redirect is ultimately executed by JavaScript.
Is Your App Protected?
VAS automatically scans for vulnerabilities related to open redirect and provides detailed remediation guidance. Our scanner targets issues common in AI-generated applications.
Scans from $5, results in minutes. Get actionable fixes tailored to your stack.
Get Starter Scan