What Is SSRF (Server-Side Request Forgery)? A Complete Guide

You might assume internal services are safe from external attackers because they’re not exposed to the internet. SSRF attacks break that assumption by making your own server do the requesting, borrowing its network position and implicit trust to reach systems you thought were protected. The Capital One breach proved a single forged request can cost hundreds of millions when cloud permissions aren’t scoped correctly. We’re explaining how attackers chain SSRF with metadata access, which validation gaps matter most, and the specific cloud configurations that actually limit blast radius when prevention fails.

TLDR:

• SSRF tricks servers into fetching unintended destinations, exposing cloud credentials and internal systems
• AWS metadata endpoints at 169.254.169.254 return IAM credentials without authentication by default
• The Capital One breach exposed 100M+ records through one SSRF request that retrieved overprivileged credentials
• IMDSv2 on AWS requires session tokens that block basic SSRF; must be configured manually, not on by default
• Gecko Security finds SSRF vulnerabilities traditional SAST misses by tracing unvalidated URL flows to internal endpoints

What Is SSRF (Server-Side Request Forgery)?#

Server-Side Request Forgery (SSRF) is a web security vulnerability where an attacker tricks a server into making HTTP requests to an unintended destination. Instead of the server fetching a resource for legitimate purposes, the attacker redirects that request toward internal systems, cloud metadata endpoints, or other targets the attacker couldn’t reach directly.

Quick note before we go further: if you searched “SSRF medical,” you’re thinking of Surgical Stabilization of Rib Fractures, a chest wall surgery. This guide covers the cybersecurity kind.

SSRF landed on the OWASP Top 10 as its own category in 2021, reflecting how frequently it appears in real breaches. The vulnerability is especially dangerous in cloud environments, where a single forged request can expose credentials that unlock an entire infrastructure.

How SSRF Attacks Work#

Most web apps fetch remote resources on behalf of users. Think URL previews, webhook calls, file imports from external URLs. The problem starts when the server accepts a user-supplied URL and fetches it without validating where that URL actually points.

Here’s the basic flow. You submit a URL. The server makes the request. You get back whatever the server received. From the server’s perspective, the request is totally legitimate. From the network’s perspective, it came from a trusted internal source.

That trust is exactly what gets exploited. Internal services often skip authentication for requests coming from within the same network. An attacker who forces the server to make requests on their behalf effectively borrows that implicit trust. A request that would be blocked at the perimeter firewall sails right through when it originates from inside.

A simple example: a server accepts a url parameter to fetch an image. Instead of https://example.com/photo.jpg, you pass http://169.254.169.254/latest/meta-data/. That’s the AWS metadata endpoint. The server fetches it, the response comes back to you, and now you have cloud credentials you were never supposed to see.

The validator never fires because the request format looks fine. There’s no malicious payload in the syntax. The vulnerability lives entirely in the logic gap between what the application accepts and what it should accept.

Types of SSRF Attacks#

Not all SSRF attacks behave the same way. The biggest dividing line is whether the attacker can see the server’s response.

There are three main variants worth knowing:

• Basic (in-band) SSRF: The response from the forged request comes back directly to the attacker. You supply a URL, the server fetches it, and the response body is returned to you. Exploiting cloud metadata endpoints or internal APIs typically falls here.
• Blind SSRF: The server makes the request, but you never see the response. Attackers rely on out-of-band techniques, pointing the server at a controlled external host and watching for incoming DNS lookups or HTTP callbacks to confirm the vulnerability.
• Semi-blind SSRF: You can’t read the full response, but you get partial signals like HTTP status codes, response times, or behavioral differences depending on whether a port is open. A fast timeout on port 22 versus a slow one on port 9200 reveals internal service info without reading a single byte.

The blind and semi-blind variants are harder to detect during testing but just as dangerous. Attackers who confirm a blind SSRF can still map internal infrastructure, exfiltrate data via DNS, or chain the issue with other vulnerabilities.

SSRF Attack Targets and Impact#

SSRF attacks are a starting point, not a dead-end. Once an attacker controls where the server makes requests, the question becomes: what’s reachable from here?

Common targets include cloud metadata endpoints (AWS, GCP, and Azure all expose them), internal admin panels, databases, and services that assume localhost requests are safe. From there, attackers can steal IAM credentials, map internal networks, or reach services like Redis and Elasticsearch that have no authentication by default.

The stakes are real. SonicWall’s 2025 Cyber Threat Report found a 452% increase in SSRF attacks from 2023 to 2024, driven largely by AI-powered tools automating what once required manual probing.

Impact spans credential theft, data exfiltration, lateral movement, and in some configurations, remote code execution when SSRF reaches services that accept commands. What makes it especially dangerous is how well it chains with other weaknesses: one forged request to a metadata service hands you credentials, those credentials unlock object storage, that storage exposes a config file with a database password. No single bug caused the breach, but SSRF opened the door.

SSRF in Cloud Environments#

Cloud environments make SSRF dramatically more dangerous because of one design decision: metadata services. Every major cloud provider exposes instance metadata at a predictable, non-routable endpoint that any process running on the server can query without authentication.

The endpoints are well-known:

• AWS: http://169.254.169.254/latest/meta-data/
• GCP: http://metadata.google.internal/computeMetadata/v1/
• Azure: http://169.254.169.254/metadata/instance

Query any of these from a compromised server and you get back IAM roles, temporary access credentials, instance configurations, and sometimes user data scripts containing hardcoded secrets. Those credentials often carry broad permissions because developers scope cloud roles for convenience instead of least-privilege. One forged request hands an attacker keys to S3 buckets, RDS instances, and secrets managers.

The Capital One breach is the canonical example. An attacker exploited an SSRF vulnerability to query the AWS metadata endpoint, retrieved IAM credentials, and accessed over 100 million customer records. The financial fallout reached nearly $300 million in litigation and settlements, plus an $80 million OCC penalty. The vulnerability itself was unremarkable. The cloud architecture turned it into a disaster.

The Capital One Breach: SSRF Case Study#

The 2019 Capital One breach is worth dissecting beyond the headline numbers already mentioned, because the attack chain itself is instructive.

The attacker targeted a misconfigured AWS WAF sitting in front of Capital One’s infrastructure. That WAF had SSRF protections disabled, which let a crafted request pass through to the internal server. From there, the server queried http://169.254.169.254/latest/meta-data/iam/security-credentials/ and returned temporary IAM credentials back to the attacker.

Those credentials had ListBuckets and GetObject permissions. The attacker ran a sync against over 700 S3 folders. No lateral movement required. No zero-day. Just one misconfigured rule, one forged request, and keys that were scoped too broadly.

The real lesson here is that SSRF becomes catastrophic when cloud permissions aren’t scoped tightly. The vulnerability opened the door, but overprivileged IAM roles let the attacker walk through every room.

Common SSRF Attack Vectors and Payloads#

SSRF vulnerabilities cluster around specific patterns in code. If your application accepts a URL from a user and fetches it server-side, that’s the risk surface.

The most common entry points:

• URL parameters that fetch remote content (?url=, ?src=, ?path=, ?feed=)
• Webhook configurations where users supply a callback endpoint
• File import features that accept URLs instead of direct uploads
• PDF or screenshot generators that render user-supplied URLs

• API integrations where the server proxies requests on behalf of a client

Common Payload Patterns#

Against unfiltered endpoints, straightforward payloads work: http://169.254.169.254/latest/meta-data/iam/security-credentials/ for AWS, or http://localhost:6379/ to probe Redis. Internal service discovery often starts with http://10.0.0.1 and increments from there.

When basic payloads get blocked, attackers shift to filter bypass techniques:

• IP encoding: http://2130706433/ (decimal form of 127.0.0.1)
• Octal notation: http://0177.0.0.1/
• IPv6 loopback: http://[::1]/
• DNS rebinding: a domain resolving to a public IP during validation but switching to an internal IP on the actual request
• URL fragments and redirects: https://attacker.com/redirect?to=http://internal-service/
• Protocol switching: file:///etc/passwd, dict://, gopher:// for non-HTTP targets

The gopher protocol deserves special mention. It lets attackers craft raw TCP payloads, meaning SSRF through gopher can interact with Redis, Memcached, or SMTP directly, which opens the door to remote code execution in certain configurations.

Allowlist bypasses through open redirects are particularly tricky. Many filters validate the initial URL but follow redirects without re-checking. A server that only allows https://trusted-domain.com can still be redirected to http://169.254.169.254/ if trusted-domain.com has an open redirect endpoint.

Blind SSRF Detection Techniques#

Blind SSRF is harder to confirm than basic SSRF, but the core detection principle stays the same: if you can’t read the response, make the server talk to something you control instead.