Open Redirect Vulnerability: Risks & Real Examples

Open Redirect: when a website trusts a URL too much 🔀

An Open Redirect is a vulnerability that occurs when an application redirects the user to a URL specified in a parameter (for example newurl or redirect) without validating that the destination belongs to a trusted domain. At first glance it seems harmless —after all, the app doesn’t expose data or execute code—, but it’s a classic vector for phishing (a link that starts with the legitimate domain but ends up on a malicious site) and can also be used to amplify denial-of-service attacks against third parties. Let’s see it in practice with the skf-labs labs in Node.js, from easier to harder.

🔍 Scenario 1 — Unvalidated redirect

The first lab is at /skf-labs/nodeJs/Url-redirection. To spin it up:

npm install
npm start

This starts the service on port 5000. The application shows a “go to new web site” button that, when intercepted with a proxy, reveals the actual request:

POST /redirect?newurl=/newsite HTTP/1.1

Step 1 — Modify the destination: the newurl parameter points to an internal path (/newsite), but nothing prevents replacing it with an external URL:

newurl=https://marca.com

The server redirects anyway. That’s the Open Redirect: the application blindly trusts the received value and doesn’t check that the destination is its own or is on an allowlist of domains.

🚫 Why this is dangerous beyond phishing: there are botnets that massively scan for hosts vulnerable to Open Redirect and use them as intermediaries to send requests against a victim domain, thereby generating a distributed denial of service without the attacker directly touching the target —the “legitimate” traffic comes from the vulnerable host.

💡 Scenario 2 — Bypassing the dot filter

The second lab, at /skf-labs/nodeJs/Url-redirection-harder, adds a filter. Intercepting again with Burp Suite and testing:

POST /redirect?newurl=/newsite
POST /redirect?newurl=https://google.es

This time the application doesn’t redirect and returns the message “Sorry, you cannot use "." in the redirect”: it’s blocking the dot in the domain.

Step 2 — Obfuscate the dot with URL-encoding: selecting the . character in Burp and using right click > Convert selection > URL > URL-encode all characters, the dot becomes %2e. The problem is that the server still interprets %2e as a regular dot and blocks it just the same.

Step 3 — Double URL-encoding: the extra twist is to also encode the % symbol, so that %2e becomes %252e. The server’s filter doesn’t recognize that double encoding as a dot, but the browser does decode it correctly when making the request. Result, testing directly in the browser:

/redirect?newurl=https://google%252ees

And the redirect works, completely bypassing the filter.

💡 Scenario 3 — No dots or slashes

The third lab, at /skf-labs/nodeJs/Url-redirection-harder2, tightens the filter even further: it now blocks both dots and slashes (/) in the redirect parameter. Here a detail of how HTTPS works comes into play: the two slashes (//) that separate the scheme from the domain in a URL are not strictly mandatory for many browsers and clients to correctly interpret the URL. That means a redirect to the external domain can be built while omitting the slashes, thereby evading that particular filter.

✅ How to approach this vulnerability in an audit

1. Test the basic redirect. Look for parameters that smell like a redirect (redirect, newurl, next, url…) and insert an arbitrary external URL:

http://example.com/?redirect=http://malicious.com

2. Explore internal redirects. Try pointing to internal resources of the infrastructure itself that shouldn’t be directly accessible:

http://example.com/?redirect=/admin

3. Exploit trust in the domain. An Open Redirect allows building links that start with the legitimate domain but end up on a phishing page that mimics the real login, taking advantage of the fact that at first glance the link “looks” trustworthy.

4. Chain it with other attacks. If the parameter isn’t properly escaped, it may be susceptible to XSS, or serve to disguise the real URL in a CSRF attack:

http://example.com/?redirect=javascript:alert('XSS')

🔐 Conclusion

The Open Redirect occurs, essentially, because a web application lets an external parameter decide where the user goes without validating that destination against a list of allowed domains or paths. As we’ve seen in the three labs, filters based on blocking specific characters (dots, slashes) are fragile: double URL-encoding or the details of how an HTTPS URL is parsed are enough to bypass them. The correct mitigation isn’t about filtering characters, but about validating the destination against an allowlist of known domains or paths, or using internal identifiers (such as an index) instead of accepting full URLs from the user. To dive deeper into the recommended mitigation techniques, the OWASP Cheat Sheet on Unvalidated Redirects and Forwards is a must-read reference.