Notes from triaging forty SSRF reports

Forty SSRF reports in a year sounds impressive until you see the distribution.

About half were the same bug: a URL parameter that the backend fetched for an image preview. The fix was one allowlist on the fetch client, applied in three services. The reports were real, but they were one finding counted forty times.

A quarter were redirects. Someone validated the host, then followed a 302 to 169.254.169.254. The lesson isn't 'validate twice', it's that the fetch client has to be the thing that enforces the rule, not the controller above it.

The rest were genuinely interesting, including two that reached internal admin panels through a proxy we forgot we had.

What changed after: every fetch goes through one internal client with an allowlist and a five-second timeout, and it logs the resolved IP, not the hostname. We also wrote a tiny canary endpoint that reports if it ever gets hit.

Volume is not signal. One allowlist did more than forty tickets.