iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A redirect guard can reject an unsafe returnTo value and still send a visitor off-site if a different value—such as the request path—reaches the same redirect. In a report about the Node.js package cas-authentication-user, maintainer Seth Wheeler described that exact failure: a request path was parsed into a protocol-relative URL and used as the fallback after the return target was rejected.
How the rejected redirect target was rebuilt
Wheeler’s account says version 0.3.0 added isSafeReturnTo to reject targets beginning with forms such as //host and /\host. But the redirect code had another input: the request path. Reviewing only the query parameter left that second route to the redirect sink unchecked.
In the reported example, a request path of /\bad.example.com was parsed by Node’s legacy url.parse as a pathname of //bad.example.com. When the query-supplied return target was rejected, a fallback could use that parsed pathname. A browser interprets a URL beginning with two slashes as a network-path reference, so the resulting Location can point to the named host rather than remain on the application’s site.
Free tools Windows power users keep installed
One-click scans. No signup required.
The author says the described authenticated flow did not require a returnTo parameter or a CAS ticket for this request. The report attributes both redirect paths to the fork’s first commit on July 30, 2019, and identifies two redirect sinks. Those historical and code-level details are the maintainer’s account; they were not independently verified against the repository.
#1 Best Overall
Why checking only the return URL was not enough
The failure was not simply that one filter missed a suspicious prefix. A rejected input did not end the redirect flow: a fallback value was selected, and that different value could itself be attacker-controlled. A control on one source does not secure a sink that has another path into it.
This is why a redirect review should begin at each redirect sink, then trace every value that can reach it: query parameters, request paths, defaults, error branches, and fallback assignments. Test the rejection branch as carefully as the accepted branch. If the fallback can be influenced by a request, treat it as untrusted input rather than as a safe default.
Rank #2
- Comes with secure packaging
- It can be a gift item
- Easy to read text
What the author says changed in version 0.4.0
Wheeler reports that version 0.4.0 parses request URLs with the WHATWG URL API using a base that cannot exist, checks whether parsing moves the result to another origin, and substitutes / if it does. That approach evaluates the parsed result instead of relying only on a list of suspicious prefixes.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →The author also explicitly says they cannot claim the check is complete. The report is not independent verification of the package implementation or proof that every redirect path is safe. Wheeler says no telemetry was available to determine whether either redirect had been exploited, so exploitation is unknown.
Rank #3
How to prevent open redirects in your application
OWASP advises avoiding user-controlled redirect destinations where possible. Choose the least flexible design that meets the application’s needs:
| Pattern | Destination flexibility | Validation responsibility |
|---|---|---|
| Local-only redirect | Limited to destinations within the application | Use a framework helper that enforces local destinations and choose a safe in-app destination when validation fails. |
| Server-side destination ID | Limited to destinations mapped by the application | Maintain the mapping from a short, trusted identifier to an approved destination; do not accept an arbitrary destination URL from the client. |
| Allowlisted external redirect | Permits approved external destinations | Parse and validate the destination against an explicit allowlist, then redirect using the validated value. |
Prefer local destinations when possible
Microsoft’s ASP.NET Core documentation illustrates the local-only pattern with LocalRedirect and IsLocalUrl. Its example sends a non-local return URL to a safe in-app destination. These are ASP.NET Core APIs, not recommendations for Node.js; the general lesson is to use an appropriate framework mechanism that limits redirects to local URLs.
When external destinations are necessary
Use a maintained URL parser whose interpretation is compatible with browsers and the redirect mechanism. Compare parsed components—such as scheme, canonical host, and effective port—with an explicit allowlist. Reject userinfo and ambiguous inputs, and constrain paths when the application requires it. Most importantly, redirect with the exact validated representation: do not validate one form and then transform or reconstruct an untrusted form for the redirect.
Quick Recap
A practical review for every redirect sink
- Locate every redirect sink in the application, not just code that handles a parameter named
returnTo. - Trace every assignment and branch that can supply its destination, including request paths, defaults, and rejection fallbacks.
- For each rejected input, test what value the application uses next. Include attacker-controlled request paths as well as query parameters.
- Confirm that the final destination is the same parsed and validated value that the application sends in the redirect response.
- Choose a safe in-app fallback if the destination fails validation; do not assume a fallback is safe merely because it is used after rejection.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
