Security · interactive

SSRF: server-side request forgery

Your app shows previews of links, so your server fetches any URL a user pastes. That server sits inside your network and can reach things the attacker can't. Paste these URLs and see what comes back.

https://example.com/post
A normal page · 93.184.216.34fetched
http://169.254.169.254/latest/meta-data/iam/
Cloud metadata: temporary AWS keys · 169.254.169.254blocked
http://localhost:6379/
Internal Redis · 127.0.0.1blocked
http://2852039166/latest/meta-data/
Metadata IP written as one decimal number · 169.254.169.254fetched: internal data leaked
https://evil.example/r
Public URL that redirects to an internal admin panel · 203.0.113.9 → 302 → 10.0.0.5fetched: internal data leaked

String matching stops the obvious ones, but the same IP written as a number, or a redirect, gets through: 2 leaks.

Defence

Step 2 of 4 · read left to right

1
The server is inside the fence
It can reach metadata endpoints, admin panels and databases that the internet can't.
169.254.169.254 hands out cloud credentials
2
String blocklists leak
IPs have many spellings (decimal, hex, IPv6), DNS names can point anywhere, and redirects change the target after your check.
Also DNS rebinding: a name that resolves differently the second time.
3
Check the resolved IP, every hop
Resolve, reject private/loopback/link-local ranges, connect to that exact IP, and repeat for each redirect. Allowlist domains when you can.
Use IMDSv2 so metadata needs a token.
4
Fetch from a sandbox
Run fetchers in an isolated network with egress rules, so a mistake reaches nothing valuable.
AI agents with a browsing tool have the same risk.

In production

Tools and technologies

Cloud metadata endpoints make SSRF especially dangerous.

Not tied to one language — use these names when you search docs or design a system.