Server-Side Request Forgery (SSRF) is a vulnerability class where an attacker tricks a server into sending HTTP requests on their behalf, to destinations the attacker chose rather than the application developer. Instead of exploiting a client's browser, the attacker weaponizes the trust relationship between the vulnerable server and its internal network, cloud metadata endpoints, or other backend services. The classic 2019 Capital One breach is the textbook case: attacker Paige Thompson exploited a misconfigured WAF to send a crafted request that reached AWS's Instance Metadata Service (IMDSv1), retrieved temporary IAM credentials, and used them to exfiltrate data on roughly 106 million customers. SSRF earned its own category (A10:2021) in the OWASP Top 10 and carries CWE-918. Because it abuses server-to-server trust rather than user input rendering, SSRF often bypasses firewalls, VPCs, and access controls that were designed to stop external attackers, not requests that originate from inside the perimeter.
How Does an SSRF Attack Actually Work?
An SSRF attack works by feeding a vulnerable feature — a URL fetcher, webhook, PDF generator, image importer, or API integration — a target address the developer never intended it to reach. A typical flow: the application accepts a URL parameter (say, ?avatar_url=) to fetch a remote image; the attacker instead submits http://169.254.169.254/latest/meta-data/iam/security-credentials/, the well-known link-local address for cloud instance metadata on AWS, Azure, and GCP. The server, trusted by the metadata service because the request originates locally, dutifully fetches it and returns the response — often full of temporary access keys — to the attacker. Variants target internal-only admin panels (http://localhost:8080/admin), Redis or Elasticsearch instances bound to internal IPs with no authentication, or Docker's unauthenticated API on 169.254.169.254:2375. Blind SSRF, where the response isn't returned but the side effect (a DNS lookup, a delay, an out-of-band callback to attacker infrastructure) confirms the request fired, is common enough that most bug bounty triage playbooks assume it by default.
What's the Difference Between SSRF and CSRF?
The difference is who sends the forged request: in SSRF the server sends it, in CSRF the victim's browser sends it. Cross-Site Request Forgery (CSRF) hijacks an authenticated user's browser session to submit unwanted actions to a web app the user is already logged into — think a hidden form that transfers funds when a logged-in banking customer visits a malicious page. SSRF has nothing to do with browser sessions or cookies; it exploits the backend server's own network position to reach hosts the attacker couldn't otherwise touch, such as internal-only services, cloud metadata APIs, or other tenants on a shared VPC. The two share three letters and a knack for confusing junior pentesters, but their attack surface, exploitation technique, and mitigations (CSRF tokens vs. URL/IP allowlisting) are entirely different.
Why Did the Capital One Breach Happen Through SSRF?
The Capital One breach happened because a misconfigured Web Application Firewall (ModSecurity) running on AWS was tricked via SSRF into querying the EC2 metadata service and handing back IAM role credentials with excessive S3 permissions. Filed in July 2019, the case showed how SSRF converts a "just a data-fetching bug" into full cloud account compromise: the WAF process itself had an IAM role attached (standard practice for EC2 instances), and IMDSv1 at the time had no request-header verification step, so any process on the box — legitimate or forged — could ask the metadata endpoint for temporary credentials and receive them without proving anything. Those credentials were scoped to over 700 S3 buckets. The attacker downloaded data affecting roughly 106 million individuals, and Capital One paid an $80 million civil penalty to the OCC in 2020, plus a separate $190 million class-action settlement. AWS responded by introducing IMDSv2 in November 2019, which requires a session token obtained via a PUT request — a change specifically designed to make basic SSRF-to-metadata pivots much harder.
Which Real-World CVEs Show SSRF Being Exploited?
Several high-severity CVEs show SSRF used as the first domino in a larger compromise chain. CVE-2021-21972, patched by VMware in February 2021 with a 9.8 CVSS score, let unauthenticated attackers send a crafted request to a vCenter Server plugin, achieving SSRF that led directly to remote code execution — it was mass-scanned within days of the advisory. CVE-2021-34473, one of the ProxyShell chain used against on-premises Microsoft Exchange servers in 2021, used an SSRF flaw in the Exchange Client Access Service to reach internal PowerShell endpoints pre-authentication, setting up the webshell drops that followed. Shopify's bug bounty program paid out $25,000 in 2019 for an SSRF in its internal Exchange integration that could have exposed staff mailboxes. These cases share a pattern: SSRF is rarely the end goal, it's the pivot that turns an internet-facing input field into access to internal infrastructure, cloud credentials, or authentication-adjacent services.
How Can Teams Detect and Prevent SSRF?
Teams prevent SSRF primarily by controlling what a server is allowed to connect to, not just validating that the input "looks like" a URL. Concrete controls: enforce outbound allowlists (permit only specific, known-good hostnames/IPs rather than trying to blocklist 169.254.169.254, localhost, 0x7f.1, decimal IP encodings, and every other bypass); require IMDSv2 with hop-limit 1 on every AWS EC2 instance and disable IMDSv1 account-wide; place internal services (Redis, Elasticsearch, admin panels, CI runners) behind authentication even on "trusted" internal networks; strip or re-resolve DNS after validation to stop DNS rebinding, since an attacker can register a domain that resolves to a public IP at validation time and an internal IP at request time; and disable automatic redirect-following in HTTP client libraries, since a validated URL can 302-redirect straight into your VPC. From a detection standpoint, egress monitoring that flags application servers making first-time connections to link-local ranges (169.254.0.0/16) or RFC1918 space they've never touched before is a high-signal, low-noise trigger that catches SSRF attempts other tooling misses.
How Safeguard Helps
Safeguard helps security and engineering teams close SSRF gaps before they ship and confirm which ones actually matter in a running application. Reachability analysis traces whether a vulnerable URL-fetching library or a flagged CVE like CVE-2021-21972-class SSRF sits on a code path an attacker can actually reach from an untrusted input, cutting through the noise of dependency scanners that flag every match regardless of exploitability. Griffin AI reviews pull requests for the classic SSRF patterns — unvalidated URL parameters passed to HTTP clients, missing IP-range checks, redirect-following left enabled — and explains the risk in the context of the specific data flow, not a generic advisory. SBOM generation and ingest keep an accurate inventory of every HTTP-client and URL-parsing library in use, so when a new SSRF advisory drops, teams know within minutes which services are affected instead of grepping repos. Where a fix is well-understood, such as adding an allowlist check or disabling redirects on a specific call site, Safeguard can open an auto-fix PR directly, turning a finding into a merged remediation instead of another backlog item.