Open Redirect Vulnerabilities: Detection and Prevention

An open redirect is a vulnerability where a web application redirects users to a URL specified by an attacker-controlled parameter without proper validation. The attacker crafts a link using the trusted domain that redirects the victim to a malicious site, leveraging the user's trust in the legitimate domain.

Mapped to CWE-601 and part of OWASP A01:2021 – Broken Access Control, open redirects are commonly found in login flows, OAuth callbacks, and any feature that uses a redirect_url, next, return_to, or continue parameter.

A typical vulnerable pattern:

// Vulnerable: redirects to any URL
app.get('/redirect', (req, res) => {
  res.redirect(req.query.url);
});

// Attacker's link:
// https://trusted-site.com/redirect?url=https://evil-phishing.com/login

The victim sees trusted-site.com in the link and clicks without suspicion. Their browser follows the redirect to the attacker's phishing page.

Open redirects are a phishing amplifier. The attacker does not need to compromise the trusted site—they simply abuse its redirect functionality to lend credibility to a malicious link.

The Attack Flow

• The attacker finds a redirect endpoint on a trusted domain (e.g., a bank, SaaS application, or social network)
• They craft a URL: https://mybank.com/auth?redirect=https://mybank-login.evil.com
• The victim receives the link via email, SMS, or social engineering. They inspect the URL, see the trusted domain, and click
• The trusted site redirects to the attacker's phishing page, which clones the login form
• The victim enters credentials on the phishing page, believing they are on the legitimate site

Chained Attacks

Open redirects are frequently chained with other vulnerabilities:

• OAuth token theft: An open redirect on the OAuth callback URL allows attackers to intercept authorization codes or tokens
• SSRF amplification: Server-side redirects can be used to bypass URL allowlists in SSRF protections
• XSS via javascript: protocol: If the redirect accepts javascript: URLs, it becomes a reflected XSS vector

• Google (multiple bounties): Open redirects in Google services have been repeatedly reported through the bug bounty program. Attackers use google.com redirect URLs to make phishing links appear legitimate.
• HackerOne reports: Open redirects are among the most commonly reported vulnerabilities on bug bounty platforms, found in login flows, OAuth implementations, and email verification links.
• OAuth vulnerabilities: Multiple OAuth implementations have been compromised through open redirects on callback URLs, allowing attackers to steal access tokens by redirecting the authorization code to their server.

While open redirects are rated Medium severity on their own, their role in enabling phishing and OAuth token theft makes them a critical finding in any authentication flow. Security teams increasingly treat open redirects as high-priority issues when they occur near login or OAuth endpoints.

CodeSlick identifies open redirect patterns across JavaScript, TypeScript, Python, Java, and Go:

• Redirect functions (res.redirect(), redirect(), sendRedirect(), http.Redirect()) receiving user-controlled parameters without URL validation
• Missing origin or domain validation on redirect_url, next, return_to, and continue query parameters
• Location header set with unvalidated user input

Findings are mapped to CWE-601 with OWASP A01 classification. AI-powered fix suggestions generate URL validation logic that restricts redirects to an allowlist of trusted domains or relative paths only.