Cybersecurity glossary
What is an Open Redirect?
Learn what an open redirect is, how unvalidated URL parameters send users to malicious sites, how attackers abuse redirects for phishing and OAuth, and how allowlists prevent the flaw.
Definition
An open redirect is a vulnerability in which an application forwards users to a URL taken from untrusted input without sufficient validation, allowing attackers to craft links on a trusted domain that send victims to malicious destinations.
Why open redirects matter
Users trust links that begin with a familiar brand domain. Open redirects exploit that trust: https://trusted.example/login?next=https://evil.example looks like a login link until the browser lands on a phishing kit.
The server may not be “hacked,” yet the business still lends its reputation to an attacker. Open redirects also bypass naive URL filters and can assist OAuth token/code theft when chained with weak redirect validation.
How open redirects work
Find a redirect parameter
Locate next, returnUrl, url, continue, dest, or similar inputs that trigger Location redirects.
Supply an external destination
Insert an absolute URL to an attacker-controlled site.
Craft a trusted-looking link
Distribute the trusted-domain URL via email, ads, or chat.
Victim clicks and follows
The trusted site issues a 3xx redirect to the malicious destination.
Phish or deliver malware
The attacker page harvests credentials or pushes a payload.
Optional chaining
Combine with OAuth or XSS flows for deeper account compromise.
Common vulnerable patterns
Post-login return URLs
After authentication, users are sent wherever `next` points—including off-site.
Click-tracking wrappers
Marketing redirects without host allowlists become open redirectors at scale.
Protocol-relative tricks
Values like `//evil.example` bypass checks that only strip `http://`.
Header injection hybrids
CRLF in redirect targets can turn a redirect bug into broader response attacks.
Prevention approaches
| Approach | Guidance |
|---|---|
| Allowlist paths | Map keys like `home` or `billing` to server-defined paths; ignore raw URLs |
| Allowlist hosts | If external redirects are required, match exact trusted hosts only |
| Relative-only | Accept only relative paths beginning with `/` and reject `//` and backslashes |
| Reject by default | If validation fails, send users to a safe default page—not to the attacker value |
- Inventory all redirectors: login, logout, language, docs, and marketing click hosts.
- Implement server-side allowlists; do not rely on JavaScript checks.
- Block protocol-relative URLs and encoded bypass variants in tests.
- Pay special attention to OAuth redirect_uri and post-login next parameters.
- Log blocked redirect attempts to detect phishing campaigns using your domain.
- Avoid reflecting untrusted URLs into meta refresh or JavaScript navigations.
- Add unit tests for `https://evil`, `//evil`, and `\\evil` style payloads.
- Review third-party SSO libraries for configurable open redirect behavior.
The practical takeaway
An open redirect lets attackers turn your trusted domain into a springboard to malicious sites. It is a trust and phishing problem that can also unlock OAuth abuses.
Do not redirect to arbitrary user input. Allowlist destinations, prefer server-side path maps, and fail closed to a safe default page.
Related security terms
OAuth Misconfiguration
OAuth flows are frequently abused when redirect URIs or post-login redirects are open.
HTTP Header Injection
CRLF issues in Location headers can amplify redirect weaknesses.
Cross-Site Scripting (XSS)
Sometimes chained with redirects in phishing and token theft scenarios.
Broken Authentication
Login and logout redirect parameters are common open-redirect locations.
Frequently asked questions
What is an open redirect in simple terms?
An open redirect lets attackers use your website as a jumping-off point. A link that starts with your trusted domain then silently sends the user to an attacker site.
Why are open redirects dangerous if they do not hack the server?
They borrow trust. Users and filters see your domain first, which makes phishing and malware delivery more convincing and can bypass some allowlists.
Where do open redirects usually appear?
Login return URLs, logout pages, marketing click wrappers, language switchers, documentation portals, and OAuth-related redirect parameters.
How do attackers abuse open redirects with OAuth?
They may chain an open redirect on a trusted host to steal authorization codes or tokens when redirect validation is incomplete.
How do you prevent open redirects?
Do not redirect to arbitrary user-supplied URLs. Use allowlists of permitted paths/hosts, prefer relative path maps, and reject absolute external URLs unless explicitly allowed.
Are relative redirects always safe?
Safer, but still validate. Tricks like protocol-relative URLs (//evil.example) or backslash variants can escape naive checks.
Should security scanners flag all redirects?
They should flag unvalidated user-controlled destinations. Intentional, allowlisted redirects to known partners are acceptable when enforced server-side.
References
Explore authoritative guidance and frameworks related to open redirect.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.