Glossary
What is open redirect — your trusted URL used as a springboard to another site
An open redirect lets a URL on your site forward visitors to any external site, so your trusted domain becomes a springboard for phishing. How it works, and the real defense (allowlist redirect targets, never accept external URLs) — explained defensively, no attack steps.
"The start of the URL was your real domain, but clicking it sent me to a completely different site" — that's an open redirect. Here's how it works and how to reliably prevent it (no attack steps).
Why it's dangerous
The core harm is borrowed trust in your domain.
| How it's abused | What happens |
|---|---|
| Phishing springboard | Link starts with the real domain → users and filters trust it → off to a fake site |
| Auth-flow hijack | Tampering the redirect target in OAuth-style flows to grab a token/code |
| Amplifying other bugs | Combined with SSRF or XSS to widen impact |
Why it works
It appears in features like "return the user to where they were after login," where the return URL is trusted and forwarded as-is. The "start" of the URL the user sees is the real domain, so it's hard to doubt all the way through.
Defense: don't accept external URLs
Allow only relative paths (most important)
Accept return targets like /dashboard — relative paths only — and reject full URLs (starting with http:// or //). Give no room for the user to specify a destination domain.
Match against an allowlist
If you need dynamic targets, permit only entries in a fixed set of known destinations (a map). Anything else falls back to a default page.
Don't rely on string checks
//evil, backslashes, @, and multi-encoding bypass naive filters. Change what you accept (relative + allowlist) instead of patching filters.
If you must go off-site, make it explicit
When external redirects are intended, show an interstitial ("You're leaving for an external site"). Don't forward silently.
This site's view: 'low' alone, but potent paired with phishing
Open redirects are often rated low on their own, but because they lend out your domain's trust, they become potent combined with phishing or auth hijacking. That's why a design-level move — relative paths + allowlist — kills the root efficiently. It mirrors SSRF (making the server connect anywhere): both share the defense principle of never letting the user decide the destination.
Read next
- Glossary: What is SSRF · What is XSS
- Basics: Security basics
FAQ
QWhy is an open redirect a problem?
The URL's first domain is your real, trusted one (e.g. a login page), so users and mail filters click it confidently. But the site forwards them to any external site, so your real domain becomes a springboard for phishing and a foothold for stealing tokens in auth flows.
QWhat's the top defense?
Don't accept external URLs as redirect targets. For post-login return paths, allow only relative paths (/dashboard) and match against an allowlist (a fixed set of known destinations). If you truly must send users off-site, show an interstitial that tells them they're leaving.
QIs checking for http:// enough?
No. Schemeless forms (//evil.example), backslashes, encoding, and @-based confusing URLs all bypass naive checks. Rather than judging the string, design so you never accept an external URL at all (relative paths + allowlist).