SSRF (Server-Side Request Forgery): How It Works, Examples and Protection

What is SSRF?

Many web applications fetch URLs themselves. They load an image from a URL, build a link preview or send a webhook to another system. The target address often comes from the user.

If the application does not check this address properly, an attacker can enter a different target. The server then fetches it, from inside the internal network. Firewalls that block access from outside do not help here.

The name says exactly that: the request is forged on the server side.

How an SSRF attack works

A simplified example: an application offers an "import image from URL" feature. A normal request looks like this:

POST /import
url=https://example.com/logo.png

The attacker enters an internal address instead:

POST /import
url=http://localhost:8080/admin

1. Find an entry point: The attacker looks for a feature that accepts a URL or a host name.
2. Change the target: They enter an internal address, such as localhost, a private IP address or the cloud metadata service.
3. The server sends the request: The server calls the target with its own permissions and from its own network.
4. Read the result: Depending on the application, the attacker sees the response or works out from error messages and response times what is reachable inside.

Typical entry points

• Import by URL: images, documents or feeds the server loads from an address.
• Link previews: chat and social features that fetch a page's title and preview image.
• Webhooks: users store an address the server sends events to.
• PDF and image generators: tools that render HTML and load embedded resources along the way.
• XML processing: external entities in XML (XXE) can also trigger requests.
• Internal proxies and APIs: services that pass requests on to other services and take the target from parameters.

What attackers achieve with SSRF

• Internal services: admin panels, databases or caches that only listen internally and often require no login.
• Cloud credentials: the metadata service at 169.254.169.254 can return temporary keys for the server's role.
• Network mapping: response times and errors let an attacker probe an internal network piece by piece.
• Local files: if the application allows other schemes such as file://, the attacker can read files from the server.
• Further attacks: a reachable internal interface with a vulnerability can lead all the way to code execution.

Example: the Capital One breach

In 2019, an attacker stole data on about 100 million customers of the US bank Capital One. The way in was a misconfigured web application firewall in the AWS cloud. Through it, she queried the metadata service and got the credentials of a server role. That role had too many permissions and could read storage buckets with customer data.

The case shows how SSRF and overly broad permissions work together. AWS later introduced version 2 of its metadata service (IMDSv2), which makes such attacks much harder.

Types of SSRF

• Basic SSRF: the application returns the target's response to the attacker. They see directly what can be fetched inside.
• Blind SSRF: the response stays hidden. The attacker only learns that a request took place, for example through a callback to their own server or through timing differences.

Why simple filters are not enough

A blocklist with "localhost" and "127.0.0.1" is quickly bypassed. Attackers use, among other things:

• Other notations: 127.0.0.1 can also be written as 2130706433, 0x7f000001 or [::1].
• Their own domains: a host name that points to an internal IP address looks harmless to a text filter.
• Redirects: the permitted address redirects to an internal target.
• DNS rebinding: the host name returns a permitted IP address during the check and an internal one during the actual request.
• Parser differences: the check and the request read the same URL differently.

How to prevent SSRF

1. Allowlist, not blocklist: only permit the targets the feature really needs. Where possible, let users choose from fixed options only.
2. Check the IP address after resolving: resolve the host name, check the IP address and connect to exactly that address. Block private, loopback and link-local ranges.
3. Allow only the schemes you need: https and http are usually enough. Reject schemes such as file://, gopher:// or ftp://.
4. Do not follow redirects blindly: turn them off or check every new target like the first.
5. Do not pass responses through: return only what the feature needs to the user, and no raw error messages.
6. Limit outbound traffic: use a firewall so application servers can only reach the targets they need. Features that fetch external URLs are best run in their own segment. See network segmentation.
7. Secure the metadata service: on AWS, enforce IMDSv2. It requires a session token that a simple SSRF request cannot supply.
8. Keep permissions small: cloud roles and service accounts only get the permissions they need. Then even a stolen key does little damage. See principle of least privilege.

A web application firewall can also catch known patterns. It does not replace any of these measures.

Detecting SSRF

In logs, SSRF attempts often stand out as outbound connections that do not fit. Examples are requests from a web server to 169.254.169.254, to localhost or to internal addresses it never normally talks to. If you log the outbound traffic of your application servers and alert on such targets, you spot attacks early.

A penetration test shows whether an application is vulnerable. Testers check every feature that accepts addresses, including for blind SSRF with their own callback server. SecTepe offers penetration tests for web applications and infrastructure.

SSRF in the OWASP Top 10

In the 2021 OWASP Top 10, SSRF was its own category (A10). In the 2025 edition, it became part of A01 Broken Access Control. In the CWE catalog, SSRF is CWE-918.

SSRF vs. CSRF

The names sound alike, but the attacks are different. In cross-site request forgery (CSRF), the browser of a logged-in user sends a request without the user meaning to. In SSRF, the server itself sends the request. CSRF targets the user's permissions. SSRF targets the trust the server enjoys inside the network.

Conclusion

SSRF turns a harmless feature such as an image import into a way into the internal network. This is especially dangerous in the cloud, where credentials are just one request away. The best protection combines an allowlist in the application, limited outbound traffic, a secured metadata service and tight permissions.