API7:2023 — Server Side Request Forgery

Slide 17 · The Pattern

Every SSRF scenario has the same shape. The URL was trusted. It shouldn’t have been.

Across every scenario: a URL accepted from input, fetched by the server, without validating the destination.

The Missing Question

Every SSRF vulnerability failed to ask: “Is this URL permitted to be fetched by our server — considering everything our server can reach that the user cannot?”

Not “is the URL valid HTTP?” — it was. Not “does the hostname exist?” — it did. Specifically: does fetching this URL expose our internal network, cloud credentials, or local filesystem?

Failure in each scenario

Webhook — no IP validation after DNS resolution: hostname was valid, resolved to internal IP

File import — no allowlist for permitted hosts: metadata endpoint accepted alongside legitimate URLs

Link preview — no protocol restriction: file:// worked as well as https://

The fix pattern

Allowlist permitted domains — reject everything not on the list

Resolve DNS and validate the resolved IP is not private/link-local

Restrict protocols: https:// only (or http:// if required)

Disable HTTP redirects (or validate redirect destinations)

Never return raw server responses to the client

← Back How do we fix it? →