SSRF: The Mechanism
Server-side request forgery (SSRF) occurs when an application fetches a URL or network resource that the user can influence. The HTTP request originates from the server, not the client. This is the critical property: the server makes the request from its network position, with its credentials, to destinations that may not be reachable from the public internet.
The Network Position Problem
A typical web application sits at the boundary between the internet and an internal network. Firewalls and security groups restrict inbound access from the internet to specific ports and protocols on the application server. Internal services, databases, metadata endpoints, and management interfaces are not exposed externally.
When the application makes an HTTP request to a URL the attacker controls, that request comes from inside the network perimeter. The firewall rules permitting inbound internet traffic do not apply to requests originating from the application server itself. The application server may have unrestricted access to internal services that an external attacker cannot reach directly.
SSRF is the mechanism by which an external attacker exercises a server's internal network access.
Where SSRF Surfaces
Any application feature that fetches a remote resource is a potential SSRF surface:
- Webhook configuration: users provide a URL the application will POST event data to
- URL preview and link metadata fetching: applications that fetch Open Graph tags from user-submitted URLs
- File import from URL: importing a document, image, or feed by specifying a remote URL
- PDF or screenshot generation: server-side headless browsers that render a URL
- Image processing: fetching images from remote URLs before resizing or transcoding
- XML parsers with external entity support: an XXE vulnerability that resolves external entities via HTTP
In each case the attacker substitutes a target of their choosing for the legitimate remote resource.
What the Server Sees vs. What the Client Sees
A browser enforces the same-origin policy: scripts cannot make arbitrary cross-origin requests and read responses. The server has no equivalent constraint by default. When the application's HTTP client receives a response, it may return the body to the attacker (in-band SSRF), or it may only act on the response internally, giving the attacker no direct output (blind SSRF).
In-band SSRF is the most immediate. The attacker requests an internal URL and the application returns the response body in its own response. The attacker reads internal service responses, configuration files, or metadata through the application as a proxy.
Blind SSRF confirms reachability and can be detected through out-of-band channels but does not return response content directly. Despite returning no data, blind SSRF can still reach internal services and trigger state changes.