Server-Side Request Forgery sounds modest and is anything but. You find a feature where the server fetches a URL you control (a webhook, an "import from link," a thumbnail generator, a PDF renderer) and you point it somewhere it was never meant to go.
The reason it's dangerous: the server sits inside the network you can't reach. Its requests come from a trusted source, often skip the firewall, and can hit things with no business being exposed:
http://169.254.169.254/: cloud metadata endpoints that have historically handed out credentials to anyone who asks from inside.http://localhost:PORT/: admin panels and internal services bound to loopback because "only local can reach them."- Internal hostnames and
10.0.0.0/8ranges the server can resolve and you can't.
The mental model: you're not attacking the web app, you're borrowing its network position. It becomes your proxy into the soft, chewy internal network that assumes anything talking to it is already trusted.
Worked the SSRF track on PortSwigger end to end. The labs that taught me most were the ones with a filter to bypass, because the filter tells you exactly what the developer was afraid of, and therefore exactly where the real target is.