blueredix logo
SCAN On-demand vulnerability scans from €149
info vuln-class-ssrf

Server-Side Request Forgery (SSRF), in plain English

SSRF lets an attacker make web requests from your server to anywhere the server can reach — including internal admin panels and the cloud metadata service. The Capital One breach in one short article.

What this is

Server-Side Request Forgery — SSRF — is what happens when your application takes a URL as input and fetches it on the server side, and the attacker is allowed to control the URL. The request that goes out comes from your server’s IP address, so it sails through any firewall rule that says “allow internal traffic”. The attacker gets to reach anywhere your server can reach — typically a lot more than they can reach from the public internet.

Common features that introduce SSRF:

  • Link previews. The user pastes a URL, the server fetches it to display the title and image.
  • Webhooks and integrations. The user configures a callback URL and the server posts to it.
  • PDF or image rendering services. The user supplies a URL, the server renders it.
  • Profile-picture import from a remote URL. “use this image as my avatar” and the server fetches it.
  • Pingbacks, oEmbed, RSS aggregators. Features whose entire purpose is to fetch URLs the user provides.

Why it matters

A web server normally sits on a network segment full of quiet, authenticated, “behind the firewall” services: an internal admin panel, a database without external authentication, a Kibana dashboard, an internal artefact registry. None of those are reachable from the public internet directly. They are reachable from the web server.

In the cloud, the situation gets sharper. AWS, Azure, GCP, DigitalOcean, and Alibaba Cloud all expose a metadata service at a fixed internal address that responds without any authentication and hands out the temporary credentials assigned to whatever is running on the instance. An SSRF that can reach that address can lift the credentials of the IAM role attached to your server. That is exactly how Capital One lost the data of 106 million customers in 2019 — a misconfigured firewall allowed an SSRF, the attacker hit the metadata service, picked up the role’s credentials, and used them to read every S3 bucket the role had access to.

Three concrete exploitation paths

  1. Internal HTTP services. http://10.0.0.5:8080/admin or http://localhost:9200/_cluster/health — the attacker explores the internal network from inside your application.
  2. Cloud metadata. http://169.254.169.254/latest/meta-data/iam/security-credentials/ on AWS, the equivalents on other clouds.
  3. Non-HTTP via unusual schemes. If the URL fetcher accepts schemes other than http(s) — gopher://, file://, dict:// — SSRF can read local files (/etc/passwd), interact with internal services like Redis, or talk to SMTP to send mail.

How it gets fixed

There’s no single line of code that prevents all SSRF. The fix is a combination of input validation, network segmentation, and credential hygiene. Your developer or hosting team should cover all three:

Input validation:

  • Accept only the schemes you actually need — usually http and https, never file, gopher, dict, ftp.
  • After resolving the hostname to an IP, block private and link-local ranges before fetching: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, 169.254.0.0/16, ::1/128, fc00::/7, fe80::/10. Resolve the name yourself and pass the literal IP to the HTTP client; otherwise an attacker can use a DNS-rebinding trick to slip past.
  • Limit redirects (and re-validate the target on every hop). An attacker-controlled redirect to 169.254.169.254 is the most common bypass.

Network segmentation:

  • The application server shouldn’t be able to reach internal services it doesn’t actually need. Egress firewalls work.
  • On AWS, enforce IMDSv2 (the metadata service that requires a session token) — SSRFs that can only do simple GETs no longer reach metadata. Azure and GCP have equivalent protections.

Credential hygiene:

  • IAM roles attached to your application instance should have the smallest possible permission set. If an SSRF turns into “read every customer record”, the role had no business with that level of access in the first place.

How blueredix surfaces SSRF

The scanner flags CVEs in third-party software whose description mentions SSRF, plus exposed cloud-metadata endpoints and known-vulnerable URL-fetcher products via curated nuclei templates. Actively trying to make your application fetch arbitrary URLs is penetration-testing territory, not automated scanning.

Further reading