# Open Redirects

An *HTTP redirect* is when a web-server returns an HTTP status code like 302 to tell the browser to make a request to a different URL. Redirects can also be performed in client-side JavaScript code by updating the browser URL directly.

Redirects are commonly used to push a user to an authentication page before viewing some protected content. In this scenario, the user will often be redirected again back to the original resource once they have successfully logged in.

If a redirect URL is pulled from a preceding HTTP request, you need to check the URL is safe before redirecting the user. Typically, this means checking the URL is a **relative URL** to a resource hosted under your web domain. **Open redirects** – which allow a maliciously crafted link to redirect the user to arbitrary third-party domains – are often used by spammers to disguise harmful links in emails.

## Disallowing Offsite Redirects

Relative links inside your site will always start with a single `/` character. You can prevent redirects to other domains by checking the URL being passed to the redirect function. Examine how this Java application verifies the redirect URL:

public void doPost(HttpServletRequest request, HttpServletResponse response) throws IOException {
String username = request.getParameter(“username”);
String password = request.getParameter(“password”);if (!this.credentialsAreValid(username, password)) {
request.setAttribute(“message”, “Incorrect credentials”);

HttpSession session = request.getSession(true);
session.setAttribute(“username”, username);

String destination = request.getParameter(“destination”);

if (destination == null || !this.isRelative(destination)) {
destination = “/home”;


* Allow anything starting with “/”, except paths starting “//” and “/\”.
private boolean isRelative(String url) {
return url.matches(“/[^/\\]?.*”);

This code makes sure all redirect URLs are relative paths URLs – i.e. they start with a single `/` character. (Note that URLs starting with `//` will be interpreted by the browser as a protocol agnostic, absolute URL – so they should be rejected too.)

## Check the Referrer When Doing Redirects

Another way to protect against malicious redirects is to check that the `Referer` in the HTTP request matches your domain. This ensures you are only handling redirects triggered by pages on your website:

String referer = request.getHeader(“referer”);if (referer == null || !referer.startsWith(MY_DOMAIN)) {

This will ensure attackers cannot “spoof” redirects using links into your site.

## Other Considerations

* Redirects can happen in client-side JavaScript, too. Validate any code that updates `window.location`, to ensure the URL is not taken from untrusted input.

* Some sites insert *interstitial pages* when the user is leaving the site. This is a good defense against “doppelganger” domains – websites that have a very similar domain name, that attempt to trick the user into sharing private information. However, interstitial pages are a common place for open redirect vulnerabilities to occur. If you implement an interstitial page that passes the URL in the query parameter, be sure to check the `Referer` header to prevent abuse.

* Social media and link-sharing sites often make use of redirects to do *click-counting*. URLs are chosen by the community, then when a user clicks on the link, the click-through count is incremented, and the user is redirected to their destination. In this situation, you are obligated to redirect the user to an external domains – so be sure to check the `Referer` each time you do a redirect.

## CWEs

* [CWE-601](https://cwe.mitre.org/data/definitions/601.html)

About ShiftLeft

ShiftLeft empowers developers and AppSec teams to dramatically reduce risk by quickly finding and fixing the vulnerabilities most likely to reach their applications and ignoring reported vulnerabilities that pose little risk. Industry-leading accuracy allows developers to focus on security fixes that matter and improve code velocity while enabling AppSec engineers to shift security left.

A unified code security platform, ShiftLeft CORE scans for attack context across custom code, APIs, OSS, containers, internal microservices, and first-party business logic by combining results of the company’s and Intelligent Software Composition Analysis (SCA). Using its unique graph database that combines code attributes and analyzes actual attack paths based on real application architecture, ShiftLeft then provides detailed guidance on risk remediation within existing development workflows and tooling. Teams that use ShiftLeft ship more secure code, faster. Backed by SYN Ventures, Bain Capital Ventures, Blackstone, Mayfield, Thomvest Ventures, and SineWave Ventures, ShiftLeft is based in Santa Clara, California. For information, visit: www.shiftleft.io.


See for yourself – run a scan on your code right now