What Is Server-Side Request Forgery?
URL shorteners are frequent targets for Server-Side Request Forgery (SSRF).
When a short link service checks page titles, generates link previews, or pings destinations for uptime, the backend server makes an outbound HTTP request to the user-supplied URL.
If the server does not inspect the destination IP before making that request, an attacker can use the shortener as a proxy to scan private internal networks, read cloud metadata, and query backend microservices.
The Cloud Metadata Target: 169.254.169.254
On AWS, GCP, and DigitalOcean, virtual machines access instance configuration and temporary IAM credentials through a local metadata address:
http://169.254.169.254/latest/meta-data/iam/security-credentials/
If a user pastes that address into an unprotected shortener:
Common Bypass Tricks Attackers Use
Naive filters look for simple strings like "localhost" or "127.0.0.1". Attackers bypass string checks easily:
How TLink Blocks SSRF at the Edge
To stop SSRF attacks before any network packet leaves our workers, TLink enforces a three-stage validation pipeline:
User URL -> Protocol Check -> DNS Resolution -> CIDR Subnet Block -> Approved
|
Private IP -> Rejected (HTTP 400)1. Strict Protocol Restrictions
We allow only `http://` and `https://` schemes. Dangerous protocols like `file://`, `gopher://`, `ftp://`, and `ldap://` are rejected immediately.
2. Synchronous Pre-Flight DNS Resolution
Before connecting, our worker resolves the hostname to its underlying IPv4 and IPv6 addresses. We evaluate each address against private subnets:
If the resolved IP matches any private range, the server terminates the request with an HTTP 400 error.
3. IP Pinning to Stop DNS Rebinding
When automated health workers ping a target, they connect directly to the verified public IP rather than re-querying the hostname. This eliminates time-of-check to time-of-use (TOCTOU) DNS rebinding bugs.
Security is built directly into every layer of TLink.