CWE-601: URL Redirection to Untrusted Site ('Open Redirect')

The weakness occurs when a redirect operation trusts a URL or URL component supplied through a request or another externally influenced source. An attacker can alter the destination so that a link associated with a legitimate application sends the user to an attacker-controlled site. Because the original application may remain visible in the link or flow, the redirection can make phishing pages appear more trustworthy, and it can also expose users to malware or unintended downloads. The weakness can originate in architecture and design or implementation, including assumptions that cookies, hidden fields, headers, or other indirectly received values cannot be modified.

This is a web-based, language-independent weakness involving a data flow from an externally controlled source to a redirect destination. It is characterized by insufficient restriction of redirect targets, especially when the application accepts arbitrary external URLs instead of a constrained set of destinations. The record classifies it as a simple base weakness and uses the alternate terms Open Redirect, Cross-site Redirect, Cross-domain Redirect, and Unvalidated Redirect.

The primary effects involve bypassing protection mechanisms and enabling an attacker to gain privileges or assume a user's identity. A redirected user may reach a phishing page that imitates the legitimate site, disclose credentials or personally identifiable information, and allow stolen credentials to be used against the legitimate service. The destination may also deliver malware or trigger an immediate download, and malware could support keylogging or other theft of credentials and important data. The consequences therefore affect access control, confidentiality, and other aspects of user and system security.

Use allowlist validation for redirect destinations: assume input is malicious, validate length, type, syntax, allowed values, consistency, and business rules, and accept only approved URLs or domains. Where the destination set is known, replace user-supplied URLs with fixed identifiers mapped by the application to approved paths or URLs, rejecting all other identifiers. Alternatively, require every externally supplied redirect request to include a unique, unpredictable application-generated nonce, while recognizing that this control can be bypassed through XSS. Reduce the attack surface by identifying all direct and indirect input sources, including parameters, cookies, hidden fields, headers, URL components, files, databases, environment values, and API results. An intermediate disclaimer page can warn that the user is leaving the site; require a click or use a long delay before redirecting, and avoid introducing XSS in that page. During operation, an application firewall can provide defense in depth or temporary protection when code cannot be fixed, but it may miss input vectors, be bypassed, or interfere with legitimate requests and require customization.

Manual static analysis and manual source-code review can provide high coverage with fewer false positives when all potentially vulnerable redirect operations can be assessed. Automated static analysis, including source-code, binary, or bytecode weakness analysis, can model data and control flow to find connections between input sources and redirect sinks; it may not reliably determine whether input controls the beginning of a URL, affecting false-positive reduction. Automated dynamic analysis can supply URLs to inputs and observe Location header changes, while dynamic analysis with automated interpretation can use web application, web services, and database scanners; coverage limitations mean custom redirects may be missed. Dynamic analysis with manual interpretation can use fuzz testers and framework-based fuzzers. Architecture and design review can use formal methods or correct-by-construction approaches, and inspections can provide partial coverage. The record rates the listed manual, automated static, binary or bytecode, dynamic, and review approaches as highly effective where an effectiveness rating is supplied.

Representative examples in the official record include: CVE-2005-4206, where a URL parameter loads a URL into a frame so it appears to belong to a valid page; CVE-2008-2951, where a search-script parameter enabled redirection to arbitrary sites and phishing; CVE-2008-2052, where a URL parameter enabled similar arbitrary redirection and phishing; and CVE-2020-11053, where HTML-encoded whitespace in a redirect URL bypassed validation in a Go-based OAuth2 reverse proxy and redirected an authenticated user to a malicious site. These are representative examples, not an exhaustive list of vulnerabilities.