Server-Side Request Forgery (SSRF) is a vulnerability class where an attacker manipulates a server into sending HTTP or other network requests to a destination it did not intend to reach — often internal infrastructure that's invisible from the public internet. It sits at the intersection of input validation and network architecture: an application accepts a URL, hostname, or IP address from a user (a webhook callback, an image-import feature, a PDF-generation service, a "fetch metadata from this link" field) and the backend fetches it without verifying where that request actually lands. SSRF made the OWASP Top 10 for the first time in 2021 as category A10, and it's the mechanism behind one of the largest financial-sector breaches on record — Capital One's 2019 incident affecting 106 million customers. This glossary entry breaks down how SSRF actually works, walks through real CVEs, and lays out the controls that stop it before code ships.
What is SSRF and how does an attacker trigger it?
SSRF is triggered when an application takes attacker-controlled input and uses it, directly or indirectly, as the destination or path of a server-side outbound request. The classic example is a "profile picture from URL" or "webhook test" feature: the client sends https://example.com/image.png, and the server fetches it to store or validate it. If the server doesn't restrict the target, an attacker substitutes http://169.254.169.254/latest/meta-data/iam/security-credentials/ (the AWS instance metadata endpoint) or http://localhost:8080/admin and the server — sitting inside the trust boundary — fetches it on the attacker's behalf. The request appears to originate from a legitimate, often privileged, internal host, which is exactly why firewalls and network segmentation don't stop it: the malicious request is server-side, not client-side.
Why did the Capital One breach make SSRF a household name?
The Capital One breach became the reference case for SSRF because a single misconfigured web application firewall (WAF) let an attacker pivot from a public-facing app into AWS's internal metadata service and steal credentials for over 700 S3 buckets. In March 2019, the attacker exploited an SSRF flaw in a WAF instance to query 169.254.169.254, retrieved temporary IAM role credentials, and used them to exfiltrate data on 106 million Capital One customers and applicants, including roughly 140,000 Social Security numbers and 80,000 linked bank account numbers. The company was fined $80 million by the Office of the Comptroller of the Currency in 2020, and separately paid $190 million to settle a consumer class action in 2021. The root cause wasn't a novel technique — SSRF against the EC2 metadata endpoint was already documented — it was that no control in the pipeline caught it before the WAF configuration reached production.
What is the cloud metadata attack pattern, and why is it so damaging?
The cloud metadata attack pattern is SSRF aimed specifically at the link-local metadata service every major cloud provider exposes to instances — 169.254.169.254 on AWS, GCP, and Azure — because that endpoint hands out temporary credentials with no authentication required from inside the instance. This is what turns a "minor" information-disclosure bug into full account compromise: instead of leaking a file, the attacker leaks an IAM role's access key, session token, and secret, then uses the AWS CLI or SDK directly with those credentials. AWS's response was IMDSv2, released in November 2019 as a direct consequence of the Capital One incident, which requires a session token obtained via a PUT request — a change that blocks most naive SSRF payloads because simple GET-based forgery can't complete the handshake. Despite IMDSv2 being available for over five years, Palo Alto Networks' Unit 42 and other cloud security researchers continue to find production workloads still running IMDSv1-only, leaving them exposed to the exact same attack chain.
How do blind and semi-blind SSRF differ from ordinary SSRF?
Blind SSRF differs from ordinary SSRF in that the application never returns the response body of the forged request, so the attacker has to infer success through side channels rather than reading data directly. In basic SSRF, the attacker sees the fetched content in the page — useful for reading internal admin panels or cloud metadata directly. In blind SSRF, common in webhook, PDF-rendering, or link-preview features, the attacker instead measures response timing (to fingerprint open ports on internal hosts), triggers out-of-band DNS or HTTP callbacks to an attacker-controlled listener, or watches for state changes (a deleted resource, a triggered internal API call) to confirm the request landed. Microsoft's ProxyLogon chain against Exchange Server (CVE-2021-26855, disclosed March 2021, CVSS 9.8) started as exactly this kind of server-side forged request, letting an unauthenticated attacker reach internal Exchange endpoints before chaining into remote code execution across tens of thousands of servers within weeks of disclosure.
What are the most effective technical controls for preventing SSRF?
The most effective controls combine strict allowlisting of outbound destinations with denying requests to private and link-local IP ranges at the network layer, because relying on application-level string filtering alone is consistently bypassable. Concretely: enforce an allowlist of permitted destination hosts/schemes rather than a blocklist of forbidden ones (blocklists miss encoded IPs like http://0x7f000001/, DNS rebinding, and IPv6 shorthand); resolve and validate the DNS destination server-side before connecting, then pin the connection to that resolved IP to prevent time-of-check/time-of-use rebinding; block requests to 169.254.169.254, 127.0.0.1/8, 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 at the egress firewall regardless of what the application layer decides; and require IMDSv2 with a hop limit of 1 on every EC2 instance so a forged request from inside a container can't reach the host's credentials. VMware's own vCenter Server SSRF, CVE-2021-21972 (CVSS 9.8, patched February 2021), is a case study in why defense-in-depth matters — it let unauthenticated attackers upload files and execute code through a single unvalidated plugin endpoint, and organizations that had egress controls in place limited the blast radius even before patching.
How Safeguard Helps
Safeguard's reachability analysis identifies which SSRF-prone code paths — HTTP client calls fed by user-controlled input — are actually invoked from an externally reachable entry point, so teams triage the handful of exploitable instances instead of every URL-fetch call in the codebase. Griffin AI reviews the surrounding data flow to confirm whether a flagged parameter reaches a network call without validation, cutting false positives that waste engineering time on dead code. Safeguard's SBOM generation and ingest pipeline tracks known-vulnerable versions of libraries with historical SSRF CVEs (like affected vCenter and Exchange components) across your fleet automatically, and auto-fix PRs propose the allowlist or IP-validation patch directly in the pull request, so the fix ships in the same review cycle the vulnerability is found in.