OWASP A10: Server-Side Request Forgery (SSRF)

After this lesson, you will be able to: Recognize, find, and fix Server-Side Request Forgery (OWASP A10): tricking the server into making requests to places it should not.

Server-Side Request Forgery (SSRF) is OWASP A10. The app fetches a URL the user supplies, and the attacker points it at internal systems the server can reach but they cannot, like cloud metadata endpoints, internal admin services, or the local network. It powered one of the largest cloud breaches in history.

Prerequisites:Security Logging and Monitoring Failures

What it is

SSRF happens when an application takes a user-supplied URL and makes a server-side request to it (fetching an image, a webhook, a 'preview' of a link). Because the request comes from the server, it can reach things the attacker cannot reach directly: internal-only services, databases, the loopback interface, the cloud provider's metadata endpoint (169.254.169.254), and other hosts inside the network. The attacker uses the server as a proxy into the trusted internal zone.

How to find it

Look for any feature that fetches a user-controlled URL.

1
Find features that take a URL or host from the user: link previews, webhooks, image/file fetchers, PDF generators, import-from-URL.
2
In Burp Suite, change the URL parameter to an internal target (http://169.254.169.254/, http://localhost/, an internal IP) and watch the response.
3
Use a collaborator/out-of-band tool to detect blind SSRF (the server makes the request but you do not see the body).
4
Check whether the cloud metadata endpoint is reachable from the app (a high-impact target).
5
Test URL-parsing bypasses (redirects, alternate IP encodings, DNS rebinding) against any allow-list.

How to fix it

Restrict where the server may go, and defang the metadata endpoint.

tsx

// VULNERABLE: fetches whatever URL the user sends
app.post('/preview', async (req, res) => {
  const r = await fetch(req.body.url);   // attacker: http://169.254.169.254/...
  res.send(await r.text());
});

// FIXED: validate against an allow-list + block internal ranges
function isAllowed(url) {
  const u = new URL(url);
  if (u.protocol !== 'https:') return false;
  if (!ALLOWED_HOSTS.has(u.hostname)) return false;     // explicit allow-list
  if (isPrivateOrLoopbackOrMetadata(u.hostname)) return false; // block 10/8, 127/8, 169.254/16
  return true;
}
// Also: require IMDSv2 (session-token metadata) on AWS, give the instance
// least-privilege IAM, and isolate egress at the network layer.

Quick Check

In the Capital One breach, what did the SSRF actually let the attacker reach?

Pick the best answer.

←OWASP A09: Security Logging and Monitoring Failures

Back to Application Security

Top Security Threats and the Frameworks That Map Them→