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#
Try Elido
Paste a URL, get a working short link
No signup. Link lives for 30 days. Sign up to keep it forever.
Free, no signup required · 2 per day