What is SSRF?

Server‑Side Request Forgery (SSRF) is a vulnerability where an attacker tricks your server into sending HTTP requests to locations it should never access, such as internal services or cloud metadata endpoints. Instead of attacking those systems directly, the attacker abuses your server's position inside the network and uses it as a proxy.

Why SSRF is a big deal

Modern applications constantly talk to other services: image fetchers, webhooks, PDF generators, internal APIs, and cloud platforms. Whenever your server makes a request based on user input, there is a chance for SSRF if that input is not strictly validated. A single insecure URL parameter can become a shortcut to sensitive data, internal dashboards, or even full cloud account compromise.

A simple SSRF example

Imagine a blog platform with a "preview image from URL" feature:

  • The user provides a link to an image.
  • The server downloads that image and shows a preview.

The request might look like:

GET /preview?url=https://example.com/logo.png

If the backend blindly does something like fetch(user_supplied_url), An attacker can change the URL to:

  • http://localhost/admin
  • The server fetches its own internal admin panel, normally not exposed to the internet, and may return that HTML in the preview.
  • http://169.254.169.254/latest/meta-data/
  • In a cloud environment, this special address can return instance metadata and temporary credentials belonging to the server.

Nothing fancy is required from the attacker — just control over the URL and the server's ability to reach internal targets.

What attackers use SSRF for

Once an attacker can decide where your server connects, SSRF becomes a powerful pivot point.

  • Infrastructure mapping
  • Probe internal IP ranges such as localhost, 10.x, 172.16–31.x, and 192.168.x.
  • Use differences in status codes, response sizes, and timing to discover open ports, services, and internal architecture.
  • Internal reconnaissance
  • Reach admin panels, monitoring dashboards, and microservices that were meant to be "internal only."
  • Enumerate hidden endpoints, software versions, and tech stacks that can be chained into further exploits.
  • Cloud metadata and credential theft
  • Query cloud metadata services exposed only inside instances.
  • Steal tokens or keys and then call cloud APIs directly to list buckets, read secrets, spin up resources, or modify infrastructure.

This is why SSRF appears in modern risk lists: it often starts small but can quickly lead to full environment takeover.

Common places where SSRF hides

When reviewing an application or hunting for bugs, pay special attention to features that "fetch something for the user," such as:

  • Parameters that look like URLs: url, link, target, callback, redirect, webhook, image, feed.
  • URL preview or "open graph" fetchers for links.
  • Webhooks and "test connection" features, where you can choose an endpoint.
  • PDF/image converters and "import from URL" functionalities.

Each of these may allow you to influence where the server connects. The key question is: can you redirect that connection to internal or sensitive targets?

How developers can defend against SSRF

You may not be able to remove all outbound HTTP requests, but you can significantly reduce SSRF risk with layered defenses:

  • Strict URL validation and normalization
  • Properly parse and normalize user‑supplied URLs before using them.
  • Block localhost, private IP ranges, and special addresses such as cloud metadata IPs.
  • Allow‑list destinations
  • Only allow requests to a fixed, approved set of domains or hosts that the feature actually needs.
  • Reject or rewrite every other destination.
  • Control outbound network access
  • Route outbound traffic through a proxy or egress firewall.
  • Apply network rules so application servers cannot directly reach internal management networks or metadata endpoints.
  • Harden internal services
  • Do not treat "internal" as a security boundary.
  • Require authentication and proper authorization on internal services just like you would on public endpoints.

These measures ensure that even if SSRF exists at the application layer, its impact is tightly limited by the surrounding infrastructure.

A practical mindset for SSRF

When thinking about SSRF — whether as a developer, defender, or bug hunter — use this simple chain:

  1. Is there a feature where the server makes an HTTP request for the user?
  2. Can the user control the destination of that request (host, port, path, scheme)?
  3. Can that request be aimed at internal networks, localhost, metadata endpoints, or other sensitive locations?
  4. Is there any way to observe or infer what the server sees (responses, errors, timing)?
None

If the answer is "yes" at each step, you are looking at a potentially high‑impact SSRF scenario worth prioritizing in both code reviews and penetration tests.