ssrf

Server-Side Request Forgery Detection

Overview

Server-side request forgery is when an attacker makes the application server issue an outbound request to a destination of their choosing instead of the one the developer intended. It sits at the moment a handler takes a request-derived value — a full URL, a hostname, a port, a path fragment, or a reference embedded in a parsed document — and builds an outbound client call from it. Because the request leaves the server, it carries the server's network position and implicit trust: loopback interfaces, private network segments, internal admin panels, service management ports, and the cloud instance metadata endpoint that hands out temporary credentials. The attacker is usually an unauthenticated or low-privileged external user; what they gain ranges from reading internal-only pages to stealing cloud IAM credentials to firing exploits at internal software through the server. This skill finds such flaws by locating every site where an outbound request destination can be influenced by input, checking each site in parallel, and merging the results into <output_dir>/ssrf-results.md.

What it is NOT

• Open redirection (/websec:open-redirect, or /websec:dom-based when client JavaScript performs the navigation): a redirect sends the victim's browser somewhere. Test: who issues the follow-up request — the browser or the server? Only the server-issued fetch belongs here. An open redirect that a server-side fetcher follows is in scope here as the filter-bypass variant; the redirect endpoint itself remains the sibling skill's finding.
• Cross-site request forgery (/websec:csrf): CSRF forges a request from the victim's browser toward this application. Same word, opposite direction.
• XML external entities (/websec:xxe): if the outbound request is produced by an XML parser resolving an entity or SYSTEM reference, the fix is parser hardening and the finding belongs to that skill. Test: is the destination taken from a URL-shaped field the handler passes to an HTTP client, or from a document the parser dereferences on its own?
• Path traversal (/websec:path-traversal): a file:// scheme reaching a local file through an HTTP client is still an outbound-client sink and stays here; a value passed to a filesystem API belongs there. Test: which sink receives the value, a network client or open/readFile?
• Host header attacks (/websec:host-header): using Host to build absolute links in emails or caches is a different flaw. It becomes SSRF only when a header value is used as an outbound fetch destination.
• Not a finding: a callback or webhook URL that is only stored, displayed, or handed to the browser and never dereferenced server-side; a destination fully determined by server-side configuration or a fixed lookup table keyed by an opaque identifier; a fetch whose host is resolved and checked against an explicit allow-list on every hop.
• An outbound client is not a candidate merely by existing. This class begins with a destination taken from a request. A service that calls its neighbours at base addresses supplied by environment variables, a settings file, or a service-discovery lookup — with only a path segment and a body derived from the request — is not exhibiting it, however many such clients it has. Record that group once with the configuration site and move on; a configured base plus a request-derived path segment returns to scope only where that segment can escape the base (an absolute URL, a leading //, or dot-segments the client resolves before connecting).