Quick answer: SSRF (Server Side Request Forgery) is when an attacker tricks a web application into making a request on the server's behalf. If the application makes a request to an address the user provides (for example a feature that fetches an image, verifies a webhook or previews a URL), the attacker can turn that address toward a resource on the internal network. This reaches internal services closed to the outside world, admin panels and especially cloud providers' metadata service. In cloud environments SSRF is dangerous enough to compromise a server on its own, and it sits as A10 in the OWASP Top 10 2021. The definitive solution is limiting the addresses the server may reach with a strict allow list and restricting egress to the internal network.

The fastest rising flaw in web security in recent years is SSRF, and the reason is the cloud. Modern applications constantly make requests to each other: verifying a webhook, fetching an image remotely, generating a link preview. These innocent looking features turn into a weapon if the attacker can control them. This article explains how SSRF works, why it is so dangerous in the cloud and how to close it.

How SSRF works

Imagine an application with a feature that fetches an image from a URL the user provides. The user gives an address, the server goes to it and downloads the image. In normal use the user gives https://example.com/logo.png.

But if the attacker instead gives:

http://169.254.169.254/latest/meta-data/

The server makes a request to this address from its own internal network. On many cloud providers this address is the metadata service and may contain the server's credentials and temporary access keys. By tricking the server, the attacker reaches a resource they could not reach themselves.

The root of the problem: the application makes a request to the address the user provides without validation. Because the server can reach internal resources unreachable from the outside, the attacker uses the server as a bridge.

Why SSRF is so dangerous in the cloud

SSRF is risky in every environment but far more destructive in the cloud. The reason is the metadata service.

Cloud servers obtain their identity and temporary access keys from an internal metadata address. This address is reachable only from the server itself, not from outside. SSRF opens exactly this internal access to the attacker:

  • The attacker reaches the metadata service via SSRF.
  • From there they pull the server's cloud credentials (role keys).
  • With these keys they perform operations in the cloud account up to the server's privilege: reading data, creating resources, even escalating privileges.

So a single SSRF flaw can turn into a server compromise in the cloud and spread from there to the whole account. A major, publicly reported cloud breach in 2019 happened through exactly this chain, reaching the metadata service from an SSRF flaw.

Types of SSRF

Type How it works Distinguishing aspect
Classic (in band) The response the server receives returns to the attacker Sees the result directly
Blind The response does not return, inferred indirectly Confirmed via DNS or timing
Internal network scan Making requests to internal addresses and mapping from response differences Used for network discovery

Blind SSRF is especially dangerous because even if the application shows the attacker no output, the attacker can use the server as a request machine. Because of this similarity, SSRF arises from data mixing with the target; the same logic underlies SQL injection and XSS flaws.

How to defend

The solution to SSRF is strictly controlling who the server may request. Layered defense:

  • Allow list. The most effective method. Let the server request only preapproved, known addresses. A block list (blocking specific addresses) approach is insufficient because there are too many bypass paths: different IP representations, redirects, DNS tricks.
  • Restricting internal egress. Block the application server's access to sensitive internal services and the metadata address at the network level. The server being unable to reach that address at all is the strongest defense.
  • Hardening the metadata service. Modern cloud providers offer a more secure version of the metadata service; enforcing it greatly reduces SSRF impact.
  • Validating redirects. The attacker can redirect from an allowed address to an internal one. Redirects in the response must be validated too.
  • Restricting the URL scheme. Allow only http and https; schemes such as file, gopher, dict should be closed.

SSRF is category A10 in the OWASP Top 10 2021; for the wider framework see our OWASP Top 10 guide. For the cloud side audit, our article on cloud security audit also helps.

Verification

The way to reliably find SSRF is testing:

  • Code review. Find every point that takes an address from user input and makes a server side request. Image fetching, webhook, preview and import features are classic risks.
  • Authorized penetration testing. Blind SSRF and the cloud metadata chain especially require a human expert. For how testing is planned, see our article on the penetration test process and scope.

Common mistakes

  • Trying to defend with a block list. A list of addresses to block is never complete. Use an allow list.
  • Forgetting redirects. An allowed address may redirect to an internal one. Validate after the redirect too.
  • Not hardening the metadata service. In the cloud this single step greatly reduces SSRF impact.
  • Leaving internal egress open. There is usually no reason for the application server to reach internal services, restrict it.
  • Underestimating blind SSRF. Even with no visible output, the server becomes a request machine.

Frequently asked questions

What is the difference between SSRF and CSRF? The names are similar but they differ. CSRF tricks the user's browser, SSRF tricks the server. SSRF is usually far more destructive because it provides internal network access.

Why is SSRF a cloud specific danger? The cloud metadata service contains the server's identity keys and is reachable only from the internal network. SSRF opens that internal access to the attacker.

Why is an allow list better than a block list? A block list must anticipate every address to block, and bypass paths are endless. An allow list permits only known safe addresses, which is far more robust.

Is blind SSRF dangerous? Yes. Even if the application shows the attacker no output, the attacker can use the server as a tool making internal requests.

Does a modern framework protect against SSRF? Frameworks do not protect automatically, because SSRF is in the application's business logic. Protection depends on the developer validating addresses.

Can a server be fully compromised with SSRF? In the cloud, if a server's identity keys are stolen through the metadata service chain, access up to that server's privilege becomes possible. This is a serious escalation path.

Sources

To measure whether your application is resilient against SSRF and the cloud metadata chain, contact DSET. From our Ankara Hacettepe Teknokent laboratory we provide penetration testing, cloud security audit and secure code review.