Server-Side Request Forgery

Many internet services consist of two parts: the page in the browser and a machine in the data center that does the actual work. This machine is called a server. It often fetches data itself from other addresses on the network, for example a preview image for a link a user has typed in. In Server-Side Request Forgery, an attacker abuses exactly this function. Instead of a harmless link, he supplies an address he would never be allowed to reach himself. The server dutifully fetches it and returns the result. The attacker thus uses the server as a messenger who opens doors that would otherwise be closed to him.

Why a server is a dangerous messenger

Company networks are usually structured like a building with a doorman. From the outside, you only reach the reception desk, i.e. the public website. Behind it lie databases, administration interfaces, and configuration services without strong protection. They were deliberately left weakly secured because it was assumed that only colleagues from inside would ever access them. It is exactly this assumption that an SSRF attack breaks.

Things get especially delicate with services in the cloud, i.e. on servers rented from large providers. There, an internal address exists from which a server can query its own access keys. Whoever persuades the server to fetch this address may, under certain circumstances, obtain the keys to the entire customer account. The most well-known case of this kind hit the US bank Capital One in 2019. Around 100 million customer records were captured, and the cleanup cost the company hundreds of millions of dollars.

For this reason, the security organization OWASP, which has maintained a ranking of the most important web vulnerabilities for years, lists SSRF as its own category. This is unusual: most entries there are broad classes of flaws, whereas SSRF is a very specific attack. It was included because modern applications constantly request other services.

From a harmless link to an internal address

The process is almost always the same. An application offers a field into which you can enter a web address. Typical examples are a profile picture from a foreign site, an import from another service, or a link preview. The server accepts the address and fetches it. If it does not carefully check where the journey is headed, the vulnerability is there.

Attackers then enter addresses that point to the internal network. These include the server itself or number ranges that are only assigned internally within a company. Sometimes even the response time is enough information: if an address responds quickly, a service exists there. This way the internal network can be mapped, even if the content of the response is never seen.

Protection does not consist of forbidding dangerous addresses. Such blocklists can almost always be circumvented with redirects and unusual notations for numbers. The reverse approach is effective: you define which few destinations are allowed and block everything else. In addition, the fetching service is given as few of its own privileges as possible, so that a successful hit yields little.

SSRF in security advisories and AI tools

In everyday life, the term is encountered mainly in reports about security vulnerabilities. When a vulnerability in a firewall, a chat server, or enterprise software becomes known, the abbreviation SSRF often appears in the text. Usually a request follows to install an update. Bug bounty programs, in which companies pay money for reported vulnerabilities, also tend to reward SSRF findings comparatively highly.

The topic is gaining new momentum through AI systems. Language models are increasingly being equipped with tools that can independently fetch web pages. This creates exactly the risky constellation: a server fetches addresses that originate from a text written by a stranger. However, SSRF should not be confused with Cross-Site Request Forgery. There, the browser of a logged-in user is abused; in SSRF, it is the server itself.