Skip to content
All posts

SSRF on the external surface: what a safe scan can and cannot see

1 min readssrf · owasp · web-security · appsec

Server-side request forgery (SSRF) lets an attacker make your server fetch a URL of their choosing. The classic payoff is the cloud metadata endpoint, where one unguarded fetch hands over temporary credentials. In the 2025 OWASP Top 10, SSRF folds into Broken Access Control, which is fitting: it is an authorization boundary the server forgot to enforce on its own outbound requests.

Why responsible scanning is careful here

A real SSRF exploit means making the target fetch attacker-controlled URLs. Done carelessly, that is intrusive and can hit internal systems. A read-only, production-safe scanner cannot and should not attempt full exploitation. So the honest move is to surface the SURFACE, not claim a confirmed breach.

What we flag

NANOTESTING looks for request parameters that influence a server-side fetch (URL parameters, webhook targets, "fetch this image" features) and flags them as an SSRF surface, with a confidence that reflects what an external probe can actually prove. We do not assert "SSRF confirmed" from a parameter name alone, because that would be a false positive, and false positives erode the one thing a security tool sells: trust.

What you do with it

Treat a flagged SSRF surface as a place to add an allowlist. Outbound fetches should resolve and validate the destination, reject private and link-local ranges, and block the cloud metadata IP. Pin the connection to the validated address so DNS rebinding cannot swap it after the check. The scanner points at the door; closing it is a one-time engineering fix that pays off across every parameter on that surface.

Related posts