What is SSRF and how can you reduce the risk?
Author: Domeny.ForSale editorial team Published
In brief: SSRF (Server-Side Request Forgery) is a vulnerability that lets an attacker trick an application server into sending a request to an unintended address. This can allow the server to reach resources that are not directly accessible from the internet, such as services on an internal network. Unlike CSRF, which exploits the user’s browser, SSRF involves the server itself making the request.
How SSRF works — a simple example
Imagine an application that lets you add a product photo by pasting an image address. The user supplies a URL, the address of a resource, and the server downloads the file and saves it in the shop’s catalogue. This is a convenient feature, but the application must check where it is actually connecting.
If it accepts any address, an attacker can point it to a service accessible only from the server’s network instead of an image. The application then acts as an intermediary, sending a request somewhere the attacker could not reach directly. If it also returns the retrieved content to the user, it may expose internal data.
Think of a receptionist who fetches documents from locked rooms at anyone’s request. The problem is not fetching documents in itself, but failing to check where they may be taken from and who may receive them.
Fetching data from a user-supplied address does not, in itself, mean there is a vulnerability. SSRF occurs when a user can direct a request beyond the permitted scope and the application fails to enforce appropriate restrictions.
Where SSRF occurs and what it can cause
SSRF can affect any feature that connects to another resource based on user-controlled input. Common examples include generating link previews, importing documents, downloading images and creating PDF files from web pages. Webhooks, which are automated notifications sent to a specified address, pose a similar risk.
The impact depends on which resources the server can access and how the application handles the response. Possible consequences include:
- reading information from internal services;
- discovering which services are available on the server’s network;
- accessing cloud environment metadata, which sometimes contains credentials;
- performing an operation in a service that incorrectly trusts traffic from the internal network.
SSRF does not automatically mean that the entire server has been compromised. However, the risk increases when the application has broad network access and internal services do not require authentication.
There is also blind SSRF, a variant in which the attacker cannot directly see the response from the requested resource. Not displaying the content does not eliminate the vulnerability: merely sending the request may trigger an unwanted operation or reveal information through the application’s behaviour.
SSRF vs CSRF — similar names, different mechanisms
CSRF (Cross-Site Request Forgery) involves tricking a user’s browser into making an unwanted request to an application. The browser may automatically include session data, such as a logged-in user’s cookie. The usual goal is to perform an operation with that user’s permissions.
With SSRF, the server makes the request, and the attack exploits its network access and any permissions it has. A logged-in victim is not inherently required, although the vulnerable feature itself may only be available after login.
| Feature | SSRF | CSRF |
|---|---|---|
| Who sends the request? | The application server | The user’s browser |
| What is exploited? | The server’s access and permissions | The user’s session |
| Main protective approach | Controlling connection destinations and network access | Validating state-changing requests, including through CSRF tokens |
These protections are not interchangeable. A CSRF token does not solve the problem of a server fetching data from prohibited addresses. Likewise, filtering outbound connections is no substitute for protecting the user’s session.
How to reduce the risk of SSRF
First, establish whether the application really needs to fetch data from arbitrary addresses. If an integration involves a single service, it is safer to store that service’s address in the configuration and accept only a resource identifier from the user.
When users must be able to supply addresses, apply several layers of protection:
- Restrict permitted destinations. Where the feature allows it, use an explicit allowlist of trusted hosts, ports and protocols. Do not validate addresses solely by searching for a text fragment.
- Check destination IP addresses. Account for both IPv4 and IPv6, and block prohibited ranges, including private networks, local addresses and special cloud metadata endpoints.
- Check redirects and DNS. A seemingly safe address may redirect to a prohibited resource. Validation must cover the actual connection destination, not just the initial URL.
- Restrict outbound traffic. Network rules should prevent the application from accessing services it does not need. Set timeouts and response size limits as well.
Do not automatically forward cookies, tokens or other credentials to user-supplied addresses. In a cloud environment, also consult the provider’s official documentation on protecting the metadata service.
Where to start checking your application
List the features in which the server fetches data based on an address or another value supplied by the user. For each one, establish the permitted connection destinations, how redirects are handled and what data is returned to the user.
Run tests only in your own environment or with the owner’s permission. Start with one feature, such as image import, and check whether its restrictions still work after a redirect—not just for the address entered in the form.
See also: What does www mean?
Read also
