Short links are everywhere. On business cards, in emails, behind QR codes. Services like Bitly, TinyURL, or the now-discontinued goo.gl have made URL shortening the standard. But what actually happens when you click one of these links?
Open Redirect as an Attack Vector
In the worst case, a URL shortener is an Open Redirect. This is exactly what OWASP has listed as a known security issue for years.
Users initially see only the shortener’s domain in the address bar. Whether wikipedia.org or a phishing site awaits behind it is invisible before clicking.
https://bit.ly/3xK9mPq → ???Without a preview function or domain restriction, the short link is a black box.
Phishing via Redirect Chains
Attackers deliberately use URL shorteners to disguise phishing links. The chain typically looks like this:
- The victim receives an email with a
bit.lylink - The link redirects to another shortener
- The victim ultimately lands on a fake login page
Each redirect makes detection by spam filters harder and makes it practically impossible for users to verify the actual destination in advance.
Token Enumeration and Privacy
Many URL shorteners use short, sequential, or easily guessable tokens. With a 6-character Base62 token, there are roughly 56 billion combinations — that sounds like a lot, but is searchable by machine in a manageable amount of time.
Researchers have shown that systematic brute-forcing can uncover private Google Docs links, OneDrive shares, and other sensitive URLs. Short tokens are a privacy problem.
My own redirect service therefore uses 12-character tokens with over 71 bits of entropy — roughly 3.2 quadrillion possible combinations. Additionally, rate limiting restricts the number of requests per minute.
Caching Pitfalls: 301 vs. 302
A common mistake: redirect services respond with 301 Moved Permanently. Browsers cache this redirect permanently. If the target URL changes later, the browser still follows the old destination.
302 Found is the right choice for changeable short links — combined with Cache-Control: no-store, so neither browsers nor proxies cache the redirect.
Live Demo: Dynamic QR Code
The following QR code demonstrates how static QR codes and dynamic short links work together. It always leads to the Wikipedia article of the day, without the QR code itself changing.
A cronjob updates the short link target at go.mathis-adler.dev daily. The QR code stays the same — only the redirect changes. This is exactly what dynamic short links are made for.
Why don’t I offer this service publicly? Because a public URL shortener creates exactly the problems described in this article: abuse through phishing, content moderation, liability issues, and the need to track users to detect abuse. A closed system — manageable only via API key and CLI — eliminates this attack surface completely. No registration form, no abuse reports, no moderation. Full control and zero tracking instead.
GDPR and Tracking
Most commercial URL shorteners capture the following on click:
- IP address (= personal data under GDPR)
- User agent and operating system
- Referrer and timestamp
- Geolocation based on IP
For companies using such services, this creates a data protection issue: processing occurs on third-party servers, often outside the EU, without the affected individuals’ knowledge.
A self-hosted redirect service can deliberately forgo any logging — Privacy by Design instead of a retroactive privacy policy.
Vendor Lock-In
Google discontinued goo.gl in 2018. Anyone who had printed QR codes with goo.gl links — on flyers, posters, packaging — faced a problem: the links still worked for a while, but new ones could no longer be created. Eventually, these links will die too.
The same risk exists with every external shortener. If you don’t control the domain, you don’t control whether the links will still work in a year.
Own domain + own service = full control. Even if the service is rebuilt, the domain persists and links can be migrated.
How to Do It Better
If you can’t or don’t want to go without short links, you should implement the following measures:
- Preview page: Show the destination before the redirect. Users can decide whether they want to proceed.
- Domain allowlist: Only allow redirects to trusted domains. No open redirect.
- Long tokens: At least 12 characters Base62. Makes enumeration practically impossible.
- 302 + no-store: Correct HTTP semantics for changeable links.
- No tracking: No IP addresses, no user agents, no cookies.
- Own domain: Retain control over the lifetime of the links.
Conclusion
URL shorteners are not a harmless convenience feature. They are a potential attack vector, relevant to data protection law, and a vendor lock-in risk. Anyone using them should understand the implications and make deliberate decisions.
For my portfolio, I therefore built my own redirect service that addresses the issues described above. The service is deliberately kept minimal and limited to a clearly defined use case.