web-open-redirect
Open redirect — abuse a redirect param to send users to attacker sites, and chain it (OAuth token theft, SSRF filter bypass, phishing). Load on params like redirect=, next=, url=, return=, callback=,
SKILL.mdskills/web/web-open-redirect/SKILL.md
GitHubOpen redirect
When it applies
The app redirects to a location derived from user input without validating it stays on-site. Low severity alone — but a powerful chain link.
Why it works
The redirect target is attacker-controlled and trusted. On its own it's phishing; chained, it turns other flows malicious (OAuth codes/tokens sent to your host, SSRF allowlist bypass via a redirect to an internal URL).
Method
- Find the param (
redirect/next/url/return/dest/callback) and set it to an external URL; follow the response — a 30xLocation: https://evil.com(or JS/meta redirect) confirms. - Bypass naive validation:
//evil.com,https:evil.com,https://target.com@evil.com,https://target.com.evil.com,/\evil.com, whitelisted-prefix tricks, double-encoding, CRLF. - Chain for impact:
- OAuth: if it's the
redirect_uri/return in an auth flow → steal the code/token (→web-oauth, ATO). - SSRF allowlist: allowed host that open-redirects to an internal target bypasses the filter.
- XSS:
javascript:scheme in the redirect where the sink allows it.
- OAuth: if it's the
Gotchas
- Standalone open redirect is often low/informational — lead with the chain (OAuth/SSRF) for real severity.
- Test both server 30x and client-side (JS
location, meta refresh) redirects. - Path-relative allowlists frequently miss
//and\— try them.
Verify success
The app redirects the user to an attacker-controlled origin, or (chained) a token/code is delivered to your host / an SSRF filter is bypassed.
References
PortSwigger OAuth+redirect labs; OWASP Unvalidated Redirects Cheat Sheet.