Server-Side Request Forgery (SSRF)
TL;DR
Server-Side Request Forgery (SSRF) makes the server fetch a URL of the attacker’s choosing, often reaching internal systems the attacker can’t hit directly. The fix is to validate and allow-list where the server is allowed to go, and to lock down internal metadata endpoints.
Only test apps you’re authorised to test.
What it is
Lots of apps fetch URLs on your behalf — a “preview this link” feature, an image importer, a webhook. If the app takes a URL from the user and fetches it without restriction, an attacker can point it at internal addresses the app server can reach but they can’t.
How it works
The classic target is cloud metadata (for example 169.254.169.254) or internal services on localhost and private ranges. The attacker supplies an internal URL where an external one is expected, and the server dutifully makes the request and sometimes hands back the response.
How to test for it
- Find features that take a URL or fetch remote content.
- Point them at a server you control and confirm the app actually reaches out (an out-of-band interaction).
- Then, in scope, see whether internal addresses are reachable, and whether responses come back.
How to fix it
- Allow-list the destinations the server may fetch, by host and scheme.
- Block requests to internal ranges and metadata endpoints; require metadata services to use tokens.
- Don’t return raw fetch responses to the user.
Reference: OWASP A10: SSRF.