Since this weakness does not typically appear frequently within a single software package, manual white box techniques may be able to provide sufficient code coverage and reduction of false positives if all potentially-vulnerable operations can be assessed within limited time constraints.
CWE-601 Base Draft
URL Redirection to Untrusted Site ('Open Redirect')
An open redirect vulnerability occurs when a web application uses unvalidated user input to determine the destination of a redirect, allowing an attacker to send users to an untrusted, external…
Definition
What is CWE-601?
An open redirect vulnerability occurs when a web application uses unvalidated user input to determine the destination of a redirect, allowing an attacker to send users to an untrusted, external website.
This flaw is common in features like login redirects, logout pages, or language selectors that take a URL parameter. Attackers exploit it by tricking users into clicking a legitimate-looking link that actually points to a malicious site, which can be used for phishing, malware distribution, or stealing session tokens via referrer headers.
To prevent this, developers should avoid using user input for redirect destinations altogether. If redirects are necessary, implement an allowlist of trusted, relative URLs or site-specific paths. Never rely on client-side validation or simply checking the domain name, as these can be bypassed. Server-side validation must strictly compare the intended redirect target against a predefined list of safe destinations.
Real-world impact
Real-world CVEs caused by CWE-601
-
URL parameter loads the URL into a frame and causes it to appear to be part of a valid page.
-
An open redirect vulnerability in the search script in the software allows remote attackers to redirect users to arbitrary web sites and conduct phishing attacks via a URL as a parameter to the proper function.
-
Open redirect vulnerability in the software allows remote attackers to redirect users to arbitrary web sites and conduct phishing attacks via a URL in the proper parameter.
-
Chain: Go-based Oauth2 reverse proxy can send the authenticated user to another site at the end of the authentication flow. A redirect URL with HTML-encoded whitespace characters can bypass the validation (CWE-1289) to redirect to a malicious site (CWE-601)
How attackers exploit it
Step-by-step attacker path
- 1
The following code obtains a URL from the query string and then redirects the user to that URL.
- 2
The problem with the above code is that an attacker could use this page as part of a phishing scam by redirecting users to a malicious site. For example, assume the above code is in the file example.php. An attacker could supply a user with the following link:
- 3
The user sees the link pointing to the original trusted site (example.com) and does not realize the redirection that could take place.
- 4
The following code is a Java servlet that will receive a GET request with a url parameter in the request to redirect the browser to the address specified in the url parameter. The servlet will retrieve the url parameter value from the request and send a response to redirect the browser to the url address.
- 5
The problem with this Java servlet code is that an attacker could use the RedirectServlet as part of an e-mail phishing scam to redirect users to a malicious site. An attacker could send an HTML formatted e-mail directing the user to log into their account by including in the e-mail the following link:
Vulnerable code example
Vulnerable PHP
The following code obtains a URL from the query string and then redirects the user to that URL.
$redirect_url = $_GET['url'];
header("Location: " . $redirect_url); Attacker payload
The problem with the above code is that an attacker could use this page as part of a phishing scam by redirecting users to a malicious site. For example, assume the above code is in the file example.php. An attacker could supply a user with the following link:
http://example.com/example.php?url=http://malicious.example.com Secure code example
Secure pseudo
// Validate, sanitize, or use a safe API before reaching the sink.
function handleRequest(input) {
const safe = validateAndEscape(input);
return executeWithGuards(safe);
} What changed: the unsafe sink is replaced (or the input is validated/escaped) so the same payload no longer triggers the weakness.
Prevention checklist
How to prevent CWE-601
- Implementation Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright. Use a list of approved URLs or domains to be used for redirection.
- Architecture and Design Use an intermediate disclaimer page that provides the user with a clear warning that they are leaving the current site. Implement a long timeout before the redirect occurs, or force the user to click on the link. Be careful to avoid XSS problems (CWE-79) when generating the disclaimer page.
- Architecture and Design When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs. For example, ID 1 could map to "/login.asp" and ID 2 could map to "http://www.example.com/". Features such as the ESAPI AccessReferenceMap [REF-45] provide this capability.
- Architecture and Design Ensure that no externally-supplied requests are honored by requiring that all redirect requests include a unique nonce generated by the application [REF-483]. Be sure that the nonce is not predictable (CWE-330).
- Architecture and Design / Implementation Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, filenames, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained indirectly through API calls. Many open redirect problems occur because the programmer assumed that certain inputs could not be modified, such as cookies and hidden form fields.
- Operation Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth [REF-1481].
Detection signals
How to detect CWE-601
Automated black box tools that supply URLs to every input may be able to spot Location header modifications, but test case coverage is a factor, and custom redirects may not be detected.
Automated static analysis tools may not be able to determine whether input influences the beginning of a URL, which is important for reducing false positives.
Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
According to SOAR [REF-1479], the following detection techniques may be useful: ``` Highly cost effective: ``` Bytecode Weakness Analysis - including disassembler + source code weakness analysis Binary Weakness Analysis - including disassembler + source code weakness analysis
According to SOAR [REF-1479], the following detection techniques may be useful: ``` Highly cost effective: ``` Web Application Scanner Web Services Scanner Database Scanners
Plexicus auto-detects CWE-601 and opens a fix PR in under 60 seconds.
Codex Remedium scans every commit, identifies this exact weakness, and ships a reviewer-ready pull request with the patch. No tickets. No hand-offs.
Frequently asked questions What is CWE-601?
How serious is CWE-601?
What languages or platforms are affected by CWE-601?
How can I prevent CWE-601?
How does Plexicus detect and fix CWE-601?
Where can I learn more about CWE-601?
Frequently asked questions
What is CWE-601?
An open redirect vulnerability occurs when a web application uses unvalidated user input to determine the destination of a redirect, allowing an attacker to send users to an untrusted, external website.
How serious is CWE-601?
MITRE rates the likelihood of exploit as Low — exploitation is uncommon, but the weakness should still be fixed when discovered.
What languages or platforms are affected by CWE-601?
MITRE lists the following affected platforms: Web Based.
How can I prevent CWE-601?
Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and…
How does Plexicus detect and fix CWE-601?
Plexicus's SAST engine matches the data-flow signature for CWE-601 on every commit. When a match is found, our Codex Remedium agent opens a fix PR with the corrected code, tests, and a one-line summary for the reviewer.
Where can I learn more about CWE-601?
MITRE publishes the canonical definition at https://cwe.mitre.org/data/definitions/601.html. You can also reference OWASP and NIST documentation for adjacent guidance.
Related weaknesses
Weaknesses related to CWE-601
CWE-610 Parent
Externally Controlled Reference to a Resource in Another Sphere
This vulnerability occurs when an application uses user-supplied input to reference a resource located outside its intended security…
CWE-1021 Sibling
Improper Restriction of Rendered UI Layers or Frames
This vulnerability occurs when a web application fails to properly control whether its pages can be embedded within frames or UI layers…
CWE-15 Sibling
External Control of System or Configuration Setting
This vulnerability occurs when an application allows users to directly modify critical system settings or configuration values from an…
CWE-384 Sibling
Session Fixation
Session fixation occurs when an application authenticates a user without first destroying the previous session ID. This allows an attacker…
CWE-441 Sibling
Unintended Proxy or Intermediary ('Confused Deputy')
A confused deputy vulnerability occurs when a system receives a request from a client and forwards it to an external destination without…
CWE-470 Sibling
Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')
This vulnerability occurs when an application uses unvalidated external input, like a URL parameter or form field, to dynamically decide…
CWE-611 Sibling
Improper Restriction of XML External Entity Reference
This vulnerability occurs when an application processes XML input without properly restricting external entity references. Attackers can…
CWE-73 Sibling
External Control of File Name or Path
This vulnerability occurs when an application uses unvalidated user input to construct file or directory paths for filesystem operations.
CWE-918 Sibling
Server-Side Request Forgery (SSRF)
Server-Side Request Forgery (SSRF) occurs when a web application fetches a remote resource based on user-controlled input, but fails to…
Resources
Further reading
- MITRE — official CWE-601 https://cwe.mitre.org/data/definitions/601.html
- Exploitable Redirects on the Web: Identification, Prevalence, and Defense https://www.cprogramming.com/tutorial/exceptions.html
- Open redirect vulnerabilities: definition and prevention https://img2.helpnetsecurity.com/dl/insecure/INSECURE-Mag-17.pdf
- Top 25 Series - Rank 23 - Open Redirect https://www.sans.org/blog/top-25-series-rank-23-open-redirect
- OWASP Enterprise Security API (ESAPI) Project https://owasp.org/www-project-enterprise-security-api/
- Drive-by download https://en.wikipedia.org/wiki/Drive-by_download
- State-of-the-Art Resources (SOAR) for Software Vulnerability Detection, Test, and Evaluation https://www.ida.org/-/media/feature/publications/s/st/stateoftheart-resources-soar-for-software-vulnerability-detection-test-and-evaluation/p-5061.ashx
Ready when you are
Don't Let Security
Weigh You Down.
Stop choosing between AI velocity and security debt. Plexicus is the only platform that runs Vibe Coding Security and ASPM in parallel — one workflow, every codebase.