An open redirect is when a URL that starts with your real domain sends visitors to a completely different site. 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 through your domain | 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: rated 'low' alone, but serious when combined with phishing
Open redirects are often rated low on their own, but because attackers can borrow the trust in your domain, they become serious when combined with phishing or auth hijacking. That's why a design-level fix (relative paths + allowlist) removes the cause efficiently. It mirrors SSRF (making the server connect anywhere): both share the defense principle of never letting the user decide the destination.
Open redirect vs SSRF vs phishing
An open redirect is less an attack in itself than a flaw that makes other attacks more convincing. Placing it next to related terms shows where it fits.
| Term | What happens | Who fixes it |
|---|---|---|
| Open redirect | A URL on the real site forwards the user's browser to an external site | Developers of the site with the redirect feature |
| SSRF | Not the browser but the server sends a request to the destination it was given | Developers of the site with the URL-fetching feature |
| Phishing | A fake site gets people to enter IDs, passwords or card details | Users, email receivers, and the organization being impersonated |
When a phishing link can use a real domain, both users and email filters find it harder to spot. Removing open redirects keeps your domain from being used in scams.
Example: where it matters most, sign-in integrations (OAuth)
Open redirects matter most around sign-in integrations (OAuth). After authorization, the user is sent back to the registered redirect URI carrying an authorization code or token. If the site they return to has an open redirect, the code or token may be sent on to an external site.
That is why the OAuth 2.0 Security Best Current Practice (RFC 9700, January 2025) requires two things.
- The authorization server compares redirect URIs with pre-registered ones by exact match
- Neither clients nor authorization servers expose pages that forward to an arbitrary URL taken from a query parameter
Open redirects are classified as CWE-601. On their own they are rarely rated high severity, but next to a sign-in integration they become a serious problem.
How severe it is
On its own, an open redirect is usually rated medium. A commonly seen rating is CVSS 3.1 6.1.
- The user has to open the link (UI:R)
- The impact is sending users to another site; it does not let anyone read the site's data directly
- Because the impact reaches beyond the redirecting site, it is scored as a scope change (S:C)
Don't put it off because of the number. Fix it first if it sits on the return path of a sign-in integration, or if it is already being used in phishing. To score your own case, use the CVSS calculator.
Safe helpers your framework already has
Framework features are less likely to miss a case than your own string checks. Two common examples:
| Framework | Helper | What it does |
|---|---|---|
| Ruby on Rails | Default redirect_to behavior and url_from | By default it blocks redirects to other hosts; sending users off-site requires an explicit allow_other_host: true. url_from returns the URL only if it is on the same host, otherwise nil |
| ASP.NET Core | LocalRedirect and Url.IsLocalUrl | Redirects only to URLs within the same site, and throws an exception for an external URL |
The Rails documentation warns that even with allow_other_host: true, passing a user-supplied parameter straight through is unsafe. When adding an off-site redirect feature, avoid that combination.
How to check your own site
Find parameters that take a destination
Search your code and URL list for parameters named like next, url, redirect, return_to, continue or callback, and check whether they are passed straight into a redirect.
Check how destinations are validated
See whether validation relies on prefix string matching or "does it start with http." Instead, split the URL into scheme, host and port with a URL parser and compare against an allowlist, or use the framework's safe helpers (such as LocalRedirect in ASP.NET Core).
Review your sign-in integration registrations
In your OAuth or SSO settings, check that registered redirect URIs contain no wildcards and no old URLs you no longer need.
Consider choosing destinations by ID
If you must redirect externally, accept a short ID rather than the URL itself, and look up the destination in a server-side table. OWASP recommends this approach.
Look for off-site redirects in your access logs
Search your access logs for requests where a destination parameter contains a host name other than your own. If you find any, check whether that redirect really sends people off-site, and treat it as a sign that someone may be circulating such links.
Sources (primary)
- OWASP, "Unvalidated Redirects and Forwards Cheat Sheet" — cheatsheetseries.owasp.org (IDs mapped server-side, allowlist checks on parsed URLs, warning pages)
- IETF RFC 9700, "Best Current Practice for OAuth 2.0 Security" (January 2025) — datatracker.ietf.org (exact matching of redirect URIs, no open redirectors)
- Ruby on Rails API, "ActionController::Redirecting" — api.rubyonrails.org (default protection against redirects to other hosts,
allow_other_host,url_from) - Microsoft, "Prevent open redirect attacks in ASP.NET Core" — learn.microsoft.com (
LocalRedirect,IsLocalUrl, logging non-local URLs) - MITRE, "CWE-601: URL Redirection to Untrusted Site ('Open Redirect')" — cwe.mitre.org
Read next
- Glossary: What is SSRF · What is XSS · What is phishing · What is CVSS
- Basics: Security basics