How Open Redirects Become High-Impact Bugs (Not Just “Low”)
An open redirect lets an attacker choose where a trusted site sends the browser next.
Many programs mark bare open redirects as low or informational. That is fair when nothing else chains. Your job is to show when the redirect becomes more than a weird link.
Quick takeaway: Untrusted
next=/returnUrl=/continue=parameters are starting points. Impact appears when OAuth, SSRF filters, or login flows trust that hop.
Where redirects hide
- Login and logout continue URLs
- Marketing “exit” links
- OAuth
redirect_urimishandling (related but stricter) - Language or region switchers
- Email deep links
When severity rises
1) Phishing with a trusted domain
https://bank.example/login?next=https://evil.example
Users see a real domain first. That can support social engineering. Some programs still keep this low unless brand abuse is in scope — check rules.
2) Token leakage via Referer or query bounce
If tokens appear in query strings and then bounce off-site, you may create a leak path.
3) SSRF filter bypass helper
Some SSRF defenses allow only “relative” or “same-site” starts. An open redirect on an allowlisted host can become the trampoline to internal URLs. PortSwigger labs demonstrate this pattern cleanly.
4) Chaining into XSS or cookie issues
Less common, but worth checking if the redirect lands on a javascript: URL or a dangerous scheme the app unexpectedly allows.
Comfortable testing tips
- Find redirect parameters
- Try external HTTPS destinations
- Try protocol-relative and encoded forms
- Ask: what trusts this hop?
- Only claim higher severity with a concrete chain
Fixes to recommend
Allowlist destinations. Prefer relative paths. Reject external hosts by default. For OAuth, follow strict redirect URI matching.
Original Bugflare article. Includes patterns taught in PortSwigger labs (including SSRF via open redirection). Always follow program severity guidelines.