Server-side request forgery () is the bug that turns “the server fetches a URL for you” into “the attacker reads your cloud credentials”. It sits at API7:2023 in the OWASP API Top 10 and CWE-918, and despite years of mitigations it remains one of the highest-impact findings in a cloud environment. This guide explains how reaches the metadata service, why IMDSv2 changed the game, and how to prevent it in depth.
What is#
occurs when an application fetches a URL that an attacker can influence, and the server makes the request from its own network position. Anywhere an app takes a URL — webhook configuration, document import, image fetch, PDF rendering, link preview — is a candidate.
POST /api/import
{ "url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/role" }
# the server fetches this from inside its own network → SSRF
The danger is not the fetch itself; it is where the server can reach that the attacker cannot: internal services, admin panels on localhost, and — most damaging — the cloud instance metadata service.
Why cloud metadata is the prize#
Every major cloud exposes an instance metadata service at the link-local address 169.254.169.254. It hands the instance its configuration and, critically, temporary IAM credentials for the instance’s role. An that reaches it can exfiltrate those credentials and then act as the instance across the cloud account. This is the →CloudMeta path in Pentrova’s escalation catalog, and it routinely turns a medium-looking into account-level compromise.
What IMDSv2 changed (and what it didn’t)#
In response to the Capital One breach class of incident, AWS introduced IMDSv2, a session-oriented metadata flow that requires a PUT to obtain a token before any GET, and which rejects requests carrying certain headers and enforces a hop limit. That defeats the simplest — a plain attacker-controlled GET — because the attacker usually cannot perform the token PUT step or set the required header through the vulnerable fetch.
But IMDSv2 is not a complete fix:
- It must be enforced, not merely available; instances still default to allowing v1 unless configured otherwise.
- primitives that allow full request control (some XXE-to-SSRF cases, request-smuggling, or proxies that forward methods and headers) can still complete the v2 handshake.
- Other clouds and self-managed metadata services have their own gaps.
So IMDSv2 raises the bar without removing the class.
How Pentrova detects deterministically#
Pentrova treats every URL-accepting parameter as a potential source. It supplies an internal canary URL, sends the request, and watches a dedicated out-of-band channel for the callback that proves the server made the request. Reporting on the callback — not a reflected response — is what keeps the finding deterministic, the same discipline behind Log4Shell detection. Once confirmed, the chain extends toward metadata and internal services under sandbox guardrails, so the report shows real impact without harm.
How to prevent #
prevention is defence in depth — no single control is sufficient:
- Validate and allowlist destinations. Resolve the hostname, reject private and link-local ranges (
169.254.0.0/16,127.0.0.0/8, RFC 1918), and re-check after DNS resolution to defeat rebinding. - Enforce IMDSv2 (or your cloud’s equivalent) and set a hop limit so a forwarded request cannot reach metadata.
- Block egress. Application workloads rarely need arbitrary outbound access; deny it by default.
- Isolate the metadata endpoint at the network layer where possible.
- Avoid following redirects to internal addresses on user-supplied fetches.
The OWASP SSRF prevention cheat sheet covers the validation logic in depth.
Key takeaways#
- lets an attacker make the server issue requests from its own network position.
- The highest-impact target is the cloud metadata service, which can hand over IAM credentials.
- IMDSv2 defeats simple but must be enforced and can still be bypassed by full-control primitives.
- Prevention is layered: destination allowlisting, IMDSv2, egress blocking, and DNS-rebinding checks.
FAQ#
Does IMDSv2 completely prevent credential theft?
No. It defeats the simplest attacker-controlled GET and should be enforced everywhere, but primitives with full request control can still complete the token handshake. Treat it as one layer, not the whole defence.
What is the difference between and an open redirect? An open redirect sends a user’s browser somewhere; makes the server issue a request. is more dangerous because the server can reach internal resources the user’s browser never could.
How do I test my app for safely? Supply internal canary URLs to every URL-accepting parameter and watch for an out-of-band callback that proves the server made the request. Pentrova automates this and reports only confirmed callbacks.
See how chains escalate in the platform pipeline, or start a free engagement.