Open Redirects
An open redirect forwards users to a URL taken from the request without validation, letting attackers craft trusted-domain links that land on phishing or malware pages.
Definition
An open redirect is a handler that reads a destination URL or path from a query parameter or form and issues a 3xx to it without an allowlist. The resulting link keeps your domain in the visible URL, carrying its reputation into a phishing flow. Severity ranges from nuisance to credential theft enabler, and it feeds OAuth redirect_uri weaknesses.
Context and scope
Found in login returnTo parameters, logout redirects, marketing campaign click-throughs, and SSO handoffs. Scanned for by every security audit.
Common misconceptions
- Redirects are harmless plumbing — the visible hostname is yours, which is exactly the phishing value
- Validating the hostname prefix is enough — attacker.example.com matches a naive example.com prefix check
- Relative redirects are always safe — scheme-relative URLs like //evil.example survive naive path-only checks
Anti-patterns
- Allowing absolute URLs in returnTo and trusting users to notice the address bar after the hop
- Blocking evil domains with substring matching that trivial prefixes bypass
- Redirecting through an interstitial for everything and destroying legitimate deep-link UX
Related concepts
Related examples
Authoritative source
https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html
What it is
The application trusts a client-supplied destination. An attacker sends a victim your-domain login link with a redirect parameter aimed at a fake login. The user sees the real domain, authenticates or begins to, and is carried to the impostor.
How it works
Validation must parse the destination and apply exact rules: allow only relative paths starting with a slash but not double slashes, or absolute URLs whose authority exactly matches the allowlist. Scheme-relative //host and backslash tricks defeat substring checks. Encoded and nested encodings must be decoded once, deterministically, before judging.
When to fix
Every redirect parameter everywhere, including logout and email-verification landing flows. Prefer server-side known destinations: map short codes to configured URLs instead of passing raw URLs around.
Pitfalls
OAuth flows inherit open redirects into redirect_uri validation gaps — that combination becomes full token theft. Marketing teams add tracking redirects ad hoc; route them through the same validated helper. Interstitial warning pages reduce phishing value without breaking legitimate links when scoped to external destinations only.