Thomas Siegbert IT-Security Consultant

Article

Open Redirects – When a Small Redirect Becomes a Major Risk

Published

Sometimes a single parameter such as redirect_to is enough to turn a harmless redirect into a genuine security risk.

Logo

A Small Parameter with a Major Impact

During a recent security assessment, I encountered a vulnerability that appeared unremarkable at first but could have serious consequences. A login endpoint operated by a major European provider allowed the redirect_to parameter to be manipulated so that users were redirected to any external domain after successfully signing in.

These so-called open redirects are among the quieter vulnerabilities on the web. They do not directly compromise a system, but they do enable attackers to exploit trust. In the context of phishing, social engineering, or session hijacking, that can have serious consequences.

How the Vulnerability Worked

The login flow itself followed a sensible design:

After authentication, the user was supposed to return automatically to the page they had originally requested, controlled by the GET parameter redirect_to. This is a standard flow in many web applications:

https://www.example.com/api/auth/signin/service-login?redirect_to=https://www.example.com/home

The problem:

The server did not validate the permitted redirect destination strictly enough. Carefully crafted encoding allowed line breaks (%0a%0d) to be inserted, which some systems interpreted as separators. This caused a second link to be loaded—in this case, an external domain.

Simplified example:

https://www.example.com/api/auth/signin/service-login?redirect_to=https://www.example.com%0a%0dhttps://malicious.example.org

The result:

After a successful login, the browser did not arrive at the legitimate destination. Instead, it opened the second URL on a completely different domain.

Why This Is Dangerous

The risk of an open redirect does not lie primarily in the technology, but in user trust. A link beginning with https://www.example.com appears safe and legitimate. An attacker can exploit precisely that impression, for example by directing users to a convincing phishing page.

Possible attack vectors include:

  • Phishing: Users are redirected after signing in to fake login pages or data collection sites.
  • Session theft: In rare cases, the redirect can be used to capture redirect data or tokens.
  • Trust abuse: Because the attack originates from an apparently trusted domain, users are much less likely to question it.
  • Chaining: Combined with other vulnerabilities such as XSS or OAuth misconfigurations, the impact can increase significantly.

Open redirects are therefore not merely trivial issues. They can provide an ideal starting point for targeted attacks.

Technical Overview

  • Type: Open Redirect (CWE-601)
  • Vulnerable parameter: redirect_to
  • Payload: %0a%0d (CRLF injection)
  • Severity: Medium (CVSS 4.0)
  • Attack vector: Remote, no special privileges required
  • Impact: Redirect to external sites, increased phishing risk.

How to Implement Redirects Securely

The technical solution is straightforward, but it must be applied consistently. Recommended measures include:

  1. Allowlist approach: Permit redirects only to trusted first-party domains, for example *.example.com.
  2. Strict URL parsing: Validate input according to RFC3986, rejecting encoded line breaks (%0a, %0d) and duplicate https:// sequences.
  3. Safe fallback behavior: If redirect_to is missing or invalid, redirect to a safe default page such as /dashboard.
  4. Logging: Record and monitor suspicious redirect attempts involving external domains or unusual encoding.
  5. Use framework features: Many web frameworks provide functions for handling redirects securely. Use them instead of writing custom, error-prone implementations.

A small automated test suite for authentication flows is also worthwhile to verify manipulated redirect parameters.

Conclusion

An open redirect may initially seem harmless—there is no data leak and no remote code execution.

In the right context, however, it can enable phishing campaigns, token leaks, or brand abuse. The risk arises primarily from users’ trust in apparently legitimate URLs.

The responsible team confirmed and accepted the reported finding. This demonstrates that even seemingly minor issues can be reviewed and rewarded—and provides a good example of effective security processes and the value of responsible disclosure.

Reward