Server-Side Request Forgery (SSRF): A Practical Guide

Server-side request forgery (SSRF) happens when an attacker can make your server send requests to a destination of their choosing. Because the request comes from inside your infrastructure, it can reach things the attacker never could directly.

Where SSRF appears

Any feature that fetches a URL on the server is a candidate:

• Link previews and URL unfurling.
• Importing files or images from a URL.
• Webhooks where users specify the destination.
• PDF generation from HTML that loads remote resources.
• Integrations that call user-provided API endpoints.

Why SSRF is so dangerous in the cloud

Cloud instances expose a metadata service at a link-local address, 169.254.169.254. On older configurations, a simple GET request to it can return temporary cloud credentials for the instance's role.

https://app.example.com/preview?url=http://169.254.169.254/latest/meta-data/

If the server fetches that URL and returns the response, an attacker can walk the metadata tree and retrieve credentials. From there they may read storage buckets, databases or secrets. SSRF has been at the centre of several major cloud breaches.

Other internal targets include admin panels on localhost, internal APIs without authentication, databases and caches on private IP ranges, and container orchestration APIs.

Blind SSRF

Sometimes the server makes the request but does not return the response. Attackers can still detect it with an external server they control, and use it to scan internal ports or trigger actions on internal services.

Why naive defences fail

Blocklisting localhost and 169.254.169.254 is not enough. Attackers bypass blocklists with:

• Alternative IP encodings, such as decimal or IPv6 forms.
• DNS names that resolve to internal addresses.
• DNS rebinding: a domain that resolves to a public IP when validated, then to an internal IP when fetched.
• Redirects from an allowed external URL to an internal one.

How to prevent SSRF

1. Allowlist destinations where possible. If you only need to fetch from a few domains, only allow those.
2. Resolve and validate the IP, then connect to that exact IP, rejecting private, loopback, link-local and metadata ranges.
3. Disable or re-validate redirects.
4. Use IMDSv2 on AWS, which requires a session token obtained via a PUT request, blocking simple GET-based SSRF to metadata. Use equivalent protections on other clouds.
5. Isolate fetchers. Run URL-fetching features in a separate network segment with no access to internal services.
6. Restrict egress with network policies, so servers can only reach what they need.
7. Do not return raw responses to the user unless required.

Testing for SSRF

Testing involves finding every parameter that accepts a URL or hostname, including ones hidden in JSON or file formats such as SVG and XML, and checking whether the server reaches internal or attacker-controlled destinations. Out-of-band detection is essential for blind SSRF.

SecurityInfinity agents identify URL-accepting features, test internal reachability and metadata access safely, and give a concrete fix. Start free.

Frequently asked questions

What is the impact of SSRF?

It ranges from internal port scanning to full cloud account compromise if credentials can be retrieved from metadata services.

Does IMDSv2 fully prevent SSRF?

It prevents simple GET-based theft of AWS instance credentials, but SSRF can still reach other internal services. Fix the application too.

Is SSRF part of the OWASP Top 10?

Yes. It was its own category in 2021 and is included under Broken Access Control in the 2025 edition.