Server-Side Request Forgery (SSRF) tricks a server into making a request the attacker chooses. If an app fetches a URL you supply (a webhook, an image importer, a PDF renderer), you may be able to point it inward.
Why it's dangerous in the cloud
Cloud instances expose a metadata service at 169.254.169.254 that hands out temporary credentials to anything that asks from the host. An SSRF that reaches it can read those IAM credentials - and now the attacker has your role's permissions, no exploit of the OS required. This was the core of several massive cloud breaches.
Detect it
- App servers making requests to
169.254.169.254, link-local, or internal ranges. - Outbound requests to attacker-controlled hosts originating from a web app.
- Metadata credential use from an unexpected IP shortly after.
Prevent it
- Enforce IMDSv2 (session-token required) - it blocks the simple SSRF-to-metadata path.
- Deny link-local egress (169.254.0.0/16) from app servers.
- Validate + allow-list outbound URLs; block internal ranges; don't follow redirects blindly.
- Least-privilege instance roles so a leaked credential is worth little.