Open Redirect Vulnerabilities: How Whitelist Validation Gets Bypassed
Open redirect bugs are deceptively simple — and deceptively easy to get wrong. A single string-matching mistake in a “safe domain” check can let an attacker turn a trusted login flow into a phishing weapon. Here’s a practical breakdown of how these bypasses work, based on real-world testing patterns.
Where to Look: Common Injection Points
Open redirects usually live behind a parameter that tells the app where to send the user after some action (like login). Watch for:
?next=
?redirect=
?return=
?returnUrl=
?continue=
?url=
?target=
?destination=
?callback=
?redirect_uri=A typical vulnerable pattern looks like:
https://redacted.com/login?next=Attack Payloads1. The @ Userinfo Bypass
?next=https://redacted.com@evil.com/Browsers treat everything before an @ as userinfo (like a username), not the host. So while the string contains redacted.com, the browser actually navigates to evil.com.
2. Subdomain Confusion
?next=https://redacted.com.evil.com/If the validation just checks whether redacted.com appears in the string, this passes — but the real host is redacted.com.evil.com, fully controlled by the attacker.
3. Scheme-Relative + @ Combo
?next=//redacted.com@evil.com/This starts with what looks like a whitelisted domain, but the browser resolves the actual host as evil.com.
Get Hasyyb’s stories in your inbox
Join Medium for free to get updates from this writer.
4. Encoded Character Bypass
?next=//redacted.com@evil.com/%2f..An encoded slash (%2f) can slip past weak normalization or filtering logic that only checks for literal / characters.
Quick Testing Flow
- Find a redirect parameter (
next,redirect,return, etc.) - Verify the normal redirect behavior works as expected
- Swap the value for a bypass payload
- Check for a
301/302response - Inspect the
Location:header - Confirm the browser actually lands on the attacker-controlled domain
What Makes Validation Vulnerable
Broken (substring check):
if (url.includes("redacted.com")) allow();This fails because .includes() doesn't care where in the string the match occurs — before an @, inside a subdomain, anywhere.
Fixed (proper host parsing):
javascript
const u = new URL(url);
if (u.hostname === "redacted.com") allow();Parsing the URL and comparing the actual hostname property closes off all four bypasses above.
The One-Line Takeaway
Open redirect via whitelist bypass using
@userinfo and scheme-relative URL parsing, allowing redirection to an attacker-controlled domain despite host restriction checks.
