An open redirect is a vulnerability where a web application takes a destination URL from unvalidated user input - usually a query parameter like ?next= or ?url= - and forwards the browser there without checking it. The link starts on a domain the victim trusts, so it passes inspection, and then quietly lands them somewhere else. The fix is not to stop redirecting. It is to stop letting the request decide where the redirect goes.
That distinction matters because redirects are everywhere and most of them are fine. Logging in and bouncing back to the page you wanted, handing off to a payment provider, an OAuth callback - all normal, all redirects. The bug, catalogued as CWE-601 and grouped under broken access control in the OWASP Top 10, is specifically the case where the target comes from user-controlled input and nothing validates it first. An attacker supplies their own URL, the trusted site forwards to it, and the trust transfers with the click.
I spend my days on the redirect path, so this is a topic I have opinions about. Short links are redirects by definition, which makes "is a shortener just an open redirect?" a fair question - and the answer, done right, is a clean no. We get there below. If redirect mechanics are new to you, types of redirects is the primer, and how URL shorteners work covers the redirect-tier basics.
What an Open Redirect Actually Is
Strip it to the mechanism. A page accepts a parameter naming where to go next, and uses it in an HTTP redirect without confirming it points somewhere allowed.
https://trusted.example/login?next=https://evil.example/fake-login
The victim sees trusted.example at the front and clicks. After login, the app reads next and issues a redirect to evil.example. The browser obeys, because a redirect is just a Location header and a 3xx status - the HTTP spec defines that behavior plainly and the browser has no way to know this particular target is hostile. The user, watching the address bar change after they have already trusted the link, often does not notice.
OWASP describes the core danger bluntly: the server name in the modified link is identical to the original site, which lends credibility to a malicious redirect. The vulnerability is not that the site redirects. It is that an outsider chose the destination.
Why a "Harmless" Redirect Is a Real Threat
The reflex is to shrug: so it sends someone to another website, what is the harm. The harm is borrowed trust, and it scales.
Phishing is the headline use. A link that begins with a bank, a SaaS login, or a government portal sails past the quick visual check most people do, and past a surprising number of automated filters that only inspect the leading domain. The victim arrives at a pixel-perfect fake of the login page they expected, on a domain that looked right one hop ago, and types their password. No malware, no exotic payload - just a redirect and a clone.
It gets worse when redirects sit near authentication. An open redirect in an OAuth flow can leak an authorization code or token to an attacker-controlled redirect_uri, which escalates a "minor" bug into full account takeover. That is why open redirects are a staple of bug-bounty reports rather than a footnote. The same trick also launders reputation: spammers and malware operators love bouncing through a trusted domain because it gets their real link past blocklists. We cover the broader category in the URL shortener security checklist, and the trust angle from the visitor's side in are URL shorteners safe.
How to Prevent Open Redirects
There is a hierarchy of fixes, and the top of it is the one that actually ends the problem. OWASP's cheat sheet ranks them, and the order is worth following.
- Do not take a URL from the request at all. Have the client send a short name, ID, or token, and resolve it to the full destination server-side. OWASP calls this the highest degree of protection, because the inbound request can no longer name an arbitrary target. If that pattern sounds familiar, it should: it is how a URL shortener works.
- Allowlist, do not denylist. When you must accept a destination, check it against a list of trusted hosts or a strict regex. Allow-listing fails closed - anything not explicitly permitted is rejected. Denylisting fails open, and attackers are paid to find the entries you forgot.
- Parse strictly. Reject protocol-relative URLs (
//evil.example), normalize backslashes, decode before you validate, and treat the host - not just the string prefix - as the thing to check. Most filter bypasses live in lazy parsing. - Show an interstitial as a backstop. If a redirect to an external site is unavoidable, route it through a page that names the destination and asks the user to confirm. It is friction, but it converts a silent redirect into an informed one.
The recurring theme is that safe redirects are decided by the server, from data the server already trusts - never by whatever string arrived in the query.
If you are building redirects into a product and would rather not own this failure mode, Elido's developer platform maps codes to destinations server-side by design - start with the API quickstart and never hand-roll a ?url= parameter again.
Why Short Links Are the Defense, Not the Bug
Here is the part that surprises people. A correctly built URL shortener is the textbook implementation of OWASP's number-one open redirect fix.
When a short link is created, its destination is validated and stored server-side, tied to a short code. When someone visits, the redirect tier looks up that code and forwards to the stored target. The destination never comes from the inbound request - the visitor cannot append a ?url= and bend the link elsewhere, because there is no such parameter to bend. That is exactly the token-to-URL mapping OWASP recommends, running in production millions of times a day. Architecturally this lives in our edge redirect tier, and the latency budget that pays for is the subject of hitting p95 under 15ms for redirects.
The honest caveat: a shortener can still be abused, just not via open redirect. If a platform lets anyone mint links to anything with no scanning or moderation, attackers will use its domain reputation to cloak their own malicious destinations - which is why responsible shorteners scan targets and enforce abuse policies. That is a content-moderation problem, distinct from the input-validation flaw this article is about, and worth not conflating. The related practice of deliberately hiding a destination is covered in link cloaking and URL masking explained, and the social-engineering cousin of all this - hostile QR codes - in are QR codes safe.
The One-Line Takeaway
If your code reads a destination out of the request and redirects to it, you have an open redirect waiting to be found. Map an ID to a server-side target instead, allowlist anything you cannot avoid taking from input, and parse like you expect to be attacked. Redirects are not the risk. Letting the request choose where they go is. The difference between a 301 and a 302 in 301 vs 302 redirects is a footnote next to that one rule.
Related on the Blog
Veelgestelde vragen
What is an open redirect vulnerability?
An open redirect is a flaw where a web application sends users to a destination URL taken from unvalidated input, usually a query parameter like ?next= or ?url=. Because the link starts on a trusted domain, the victim's browser and any link-scanning filter treat it as safe, but the application then forwards them to whatever site the parameter names - including an attacker's. It is classified as CWE-601 and sits under broken access control in the OWASP Top 10. The bug is the missing check, not the redirect itself.
Why are open redirects dangerous if they only send you to another site?
Because the danger is the trust the starting domain lends. A phishing link that reads https://trusted-bank.example/login?next=evil.example passes the eyeball test, survives many email filters, and lands the victim on a convincing fake login page - all while appearing to come from the real bank. Open redirects also chain into bigger attacks: they can leak OAuth authorization codes or tokens when the redirect target is attacker-controlled, turning a low-severity bug into account takeover. The redirect is the delivery mechanism, not the whole exploit.
Are URL shorteners an open redirect vulnerability?
No, not when built correctly - and the distinction is the point. An open redirect takes an arbitrary destination from user input at request time and forwards to it without validation. A short link maps a fixed code to a destination that was set and stored server-side when the link was created; the redirect target never comes from the inbound request. That server-side mapping is exactly the defense OWASP recommends against open redirects. A shortener becomes a problem only if it lets unaudited users create links to anything and lends them a domain reputation they can abuse - which is an abuse and moderation issue, not an open redirect bug.
How do you prevent open redirect vulnerabilities?
The strongest fix is to never accept a destination URL from the request at all. Have the client send a short name, ID, or token, and map it to the full target server-side - the same model a URL shortener uses. When you genuinely must accept a URL, validate it against an allowlist of trusted hosts rather than a denylist of bad ones, reject anything that is not a relative path or an approved domain, and be strict about parsing so tricks like //evil.example or backslashes do not slip through. As a last resort, route the redirect through an interstitial page that shows the destination before sending the user on.
How do attackers exploit an open redirect?
They find an endpoint that reflects a URL parameter into a redirect, then craft a link on the trusted domain with their own site in that parameter and distribute it by email, ad, or message. Variations include URL-encoding the payload to bypass weak filters, using protocol-relative URLs like //attacker.example, exploiting only the host portion while keeping a legitimate-looking path, and abusing OAuth redirect_uri handling to capture tokens. The common thread is that the victim sees and trusts the first domain and never sees the second until it is too late.
Is an open redirect a high or low severity vulnerability?
On its own an open redirect is often rated low to medium, because it does not directly compromise the server - it sends users elsewhere. But severity depends on what it chains into. Near an authentication flow it can leak OAuth tokens and lead to account takeover, which is high severity; as a phishing aid it can cause real-world credential loss that a CVSS score does not capture. Treat it by impact in context, not by the base label, and fix it regardless: the remediation is cheap and the abuse potential is not.
Probeer Elido
Plak een URL, krijg een werkende korte link
Geen aanmelding nodig. Link blijft 30 dagen actief. Meld je aan om hem voor altijd te bewaren.
Gratis, geen aanmelding nodig · 2 per dag