What is SSRF?

SSRF in plain English

Picture the reception desk of an office building. Visitors are only allowed into the lobby, while reception has keys to every room. If a visitor asks reception to “please get me the document from Room 12,” reception should first check whether the visitor is even allowed to have it. If reception skips this check, the visitor can use this detour to get at everything – including the archive or the executive offices.

With SSRF, a web server plays the role of the reception desk. Many applications load content from the internet: a profile picture from a specified address, a link preview, or data for a webhook – an automatic notification to another system. If the application doesn’t check the specified address strictly enough, an attacker can enter internal targets instead.

The name says it all: a forged request that is sent from the server side. SSRF shouldn’t be confused with CSRF, where the browser of a signed-in user is abused.

How SSRF works

1. Finding a suitable function: The attacker looks for a place where the application retrieves an address (URL) supplied from outside – for example, when importing files via a link.
2. Entering an internal target: Instead of a normal internet address, they enter an internal address, such as the admin interface of an internal system.
3. Using the server as a tool: The server sends the request from within the internal network. The firewall at the network perimeter notices nothing, because the request comes from the inside – from a trusted system.
4. Evaluating the response: The application returns the response or reveals through its behavior whether a target exists. The latter case is called blind SSRF.

SSRF is particularly critical in the cloud. There, virtual servers can retrieve information about themselves via an internal metadata service – in some cases including temporary credentials. If an attacker extracts them via SSRF, they can access other cloud resources in the server’s name, such as data storage.

A practical example

A software provider runs a cloud platform for event planning. Customers can upload their company logo via a link. During a penetration test, the testers enter the address of the internal metadata service instead of an image link. The platform returns the response as a supposedly broken image – complete with the server’s temporary credentials.

These credentials have far more privileges than necessary, including read access to the storage that holds all customer documents. The provider restricts the logo function to vetted image sources, blocks internal address ranges, enforces the metadata service’s protective features, and reduces the server’s privileges to the bare minimum.

Why does this matter for businesses?

SSRF undermines a widespread assumption: that internal systems are safe as long as they can’t be reached from the outside. Through a single vulnerable server, attackers can reach internal admin interfaces, databases, or cloud credentials. A harmless-looking function can thus quickly turn into a data leak or even the takeover of entire cloud environments.

Its importance is also reflected in the standards: the OWASP Top 10, the best-known overview of the most critical security risks for web applications, listed SSRF as a separate category for the first time in 2021. In the 2025 edition, SSRF falls under Broken Access Control. The 2023 OWASP API Security Top 10 lists SSRF as a risk in its own right.

How to protect your organization

• Define permitted destinations: The application only retrieves addresses from a fixed list of allowed domains and protocols.
• Block internal addresses: Internal address ranges are blocked. What gets checked is the actual destination address, not just the name entered – otherwise the block can be bypassed with tricks.
• Control redirects: The application doesn’t follow redirects automatically, or it checks every new destination again.
• Limit outbound traffic: Allow servers to establish only the connections they really need. Clean network segmentation further limits what can be reached.
• Secure the metadata service: Enable and enforce its protective features – such as the requirement to request a special session token before any query. Simple SSRF requests fail at this hurdle.
• Minimize privileges: Give cloud servers only the permissions they need for their task.
• Filter responses: The application doesn’t pass retrieved content on to users unchecked. A logo import, for example, only returns genuine image data.

How Rootsektor can help

In a cloud penetration test, we check whether attackers can obtain credentials through vulnerabilities such as SSRF and escalate their privileges in your cloud environment. We test applications and APIs in a web application penetration test and an API penetration test. The retest of remediated vulnerabilities is free of charge.