Half the features in a modern app fetch a URL on behalf of a user. Webhook receivers, image proxies, link previews, 'import from URL' buttons, third-party integrations. Every one of them is a small polite helper the server runs. Every one of them will happily run against your own internal network unless you teach it not to.
Server Side Request Forgery is when your server makes an outbound HTTP call on behalf of a user — webhook, preview, image proxy, import-from-URL — and the user gets to choose the destination. The server is inside your network. The user is not. Suddenly the user can reach things only the server was supposed to see.
What your AI actually built
You asked for a webhook endpoint that lets users register a callback URL. Or an image proxy so avatars load through your CDN. Or a link unfurler for pasted URLs. The model gave you a tidy fetch call wrapped in a route.
What it did not give you was the allowlist. The fetch will go anywhere the DNS resolver points — including 169.254.169.254 (cloud metadata), 127.0.0.1 (whatever is bound to loopback), and 10.0.0.0/8 (your internal services). To the server, all three look like perfectly valid URLs.
The really painful version is the redirect trick. You block localhost in the handler, the model says 'great, safe,' and then attacker.com returns a 302 pointing at 169.254.169.254 and the fetch follows it. The check happened once. The network call happened twice.
How it gets exploited
A SaaS app ships a nice feature: paste any URL and we will generate a preview card.