Server-Side Request Forgery in Cloud-Hosted SaaS Products

SSRF is a bug that tricks a server into making a request on the attacker's behalf. In a traditional data center that's bad enough, but in cloud-hosted SaaS, that same bug puts the attacker one hop away from the IAM credentials, secrets, and internal APIs that run the whole product. I've spent years testing these environments, and the pattern is always the same: teams underestimate SSRF because it doesn't look like much on paper, and it looks like a URL field, yet it behaves like an infrastructure breach.

The reason is architectural, not accidental. Cloud platforms build in metadata endpoints, well-known IP addresses like 169.254.169.254, that hand out temporary credentials to any process running on the instance, with no login and no token exchange required. That design makes cloud infrastructure fast to build on, but it also means that once a server can be tricked into fetching a URL of the attacker's choosing, the attacker isn't just poking around your internal network anymore, and they're one request away from your IAM role.

How an SSRF exploit actually unfolds in a cloud-hosted SaaS product

Every SaaS product I've tested has some version of the same feature set that makes SSRF possible: outgoing webhooks, link previews, PDF or document generation, image processing, third-party integrations that call user-supplied endpoints. Each one asks the server to fetch a URL that a user controls, at least in part, and that's the whole vulnerability class in a sentence.

Here's how the exploit actually plays out, step by step.

First, the attacker finds a field that accepts a URL, maybe it's a webhook callback, maybe it's a "import from URL" button, and points it at the cloud metadata service instead of a real endpoint. Second, the metadata service answers without asking who's asking, handing back temporary access keys and session tokens tied to whatever IAM role the instance carries. Third, the attacker takes those credentials and starts calling AWS, GCP, or Azure APIs directly: listing S3 buckets, pulling secrets out of Secrets Manager, querying internal databases the application server was never supposed to expose. Fourth, depending on how permissive that IAM role is, they escalate: create a new IAM user, loosen a security group, or just start exfiltrating everything the role can reach.

Capital One in 2019 is the case everyone in this field studies, because it's the clean version of the chain: one SSRF flaw, one pivot through the metadata service, and data belonging to more than 100 million people in the U.S. and 6 million in Canada was exposed. There was no zero-day in AWS itself, just a server that fetched a URL it shouldn't have, and a metadata endpoint that answered without asking questions.

This isn't a 2019 problem that got patched and went away, either. Oracle EBS CVE-2025-61882 showed active SSRF exploitation being used for remote code execution, serious enough that CISA issued an urgent patch deadline in October 2025. SSRF didn't get old; it got more valuable as more infrastructure moved to the cloud.

What this chain proves, over and over, is that the blast radius of an SSRF bug isn't set by the application, and it's set instead by whatever the IAM role attached to that server can touch.

The cloud features that turn a moderate SSRF into a critical one

Not every SSRF finding ends in a Capital One-scale breach, and what decides the severity is the cloud configuration sitting underneath the bug.

IMDSv1 versus IMDSv2 matters more than most engineering teams realize. IMDSv1 answers any GET request, no headers required, making it about as SSRF-friendly as a metadata service could possibly be. IMDSv2 requires a session-oriented PUT request first, which raises the bar. But it doesn't eliminate the risk; if application code follows redirects blindly, or can be tricked into issuing that preflight PUT on the attacker's behalf, IMDSv2 gets bypassed too.

Then there's IAM role scope. Plenty of SaaS applications run on instance roles with permissions far beyond what the application actually needs, because it was easier to grant broad access once during setup than to scope it down later. An attacker who steals that role's token inherits everything the role can do, not just what the app uses day to day. Wiz's 2025 Cloud Data Security Report found that 35% of cloud environments have compute assets that both expose sensitive data and carry critical or high-severity vulnerabilities. SSRF is one of the most direct paths into that overlap.

Internal network topology compounds it further. VPCs are full of databases, caches, admin panels, and internal APIs that were never meant to be internet-facing, but they're perfectly reachable from inside the VPC, which is exactly where an SSRF-compromised server sits. Add in service-to-service trust, where internal microservices assume any caller from within the network is legitimate, and you've got a server that can talk to anything, credentialed as anything, with nobody checking.

The toxic combination is SSRF plus an overpermissioned role plus no network segmentation. Any one of those alone is a finding worth fixing, while all three together form a single-step path to full account compromise.

SaaS products get hit here disproportionately because feature velocity outpaces security review. Every new "connect your calendar" or "auto-import from this link" feature is another URL-fetching primitive, shipped fast, reviewed later if at all. Salesforce products including Tableau, OmniStudio, and MuleSoft have all surfaced SSRF issues alongside related code execution and information disclosure findings, according to IBM X-Force. This isn't a knock on Salesforce specifically; it's what happens at scale when a product ships integrations faster than it audits them.

Why automated scanners routinely miss SSRF in SaaS applications

Scanners are good at the version of SSRF that shows up in a tutorial. Inject a known payload into an obvious field, check whether an outbound request lands on a callback server, flag it if it does. That catches the easy cases, but it misses almost everything else.

Blind SSRF is the first blind spot, and the name says it plainly: the server makes the request, but nothing comes back to the attacker, with no output and no confirmation on screen. A scanner sees nothing and reports nothing, even though credentials might be getting harvested out-of-band the entire time.

Multi-step SSRF is the second. Some vulnerable requests only fire after a specific sequence of authenticated actions, register a webhook, wait for an event, then the server calls out. Scanners don't model application state that way; they test endpoints in isolation, not workflows.

Indirect parameters trip scanners up too. A URL buried inside a JSON body, an XML payload, or a deserialized object often never gets unpacked and tested, because the scanner is looking for a URL parameter, not a URL hiding three fields deep in a nested structure.

And business logic entry points are close to invisible to a point-in-time scan, since a webhook that only fires its outbound request 24 hours after registration isn't going to trigger during a scan window that lasts minutes.

Filter bypass adds another layer scanners tend to miss entirely. Applications that implement blocklists, rejecting "169.254.x.x" or "localhost", can usually be circumvented with decimal IP notation, IPv6 representations, DNS rebinding, or redirect chains. A scanner checks the obvious blocked string, while a human tester checks every representation of that same address.

This creates a real problem for compliance-driven testing. A scan-and-report engagement for SOC 2 or ISO 27001 can come back with zero SSRF findings, not because the application is clean, but because the scanner only looked where SSRF is easy to find. Bug bounty data backs this up: severe SSRF findings carry payouts reaching $50,000, because proving the exploit requires reasoning about how the application actually behaves under a specific sequence of steps — the kind of reasoning tools aren't built to do.

A clean automated scan on SSRF tells you almost nothing, but a clean result from a human tester who mapped every URL-fetching feature and actually attempted metadata access is evidence worth trusting.

What a rigorous SSRF assessment actually covers in a cloud SaaS environment

A real SSRF assessment doesn't start with payload injection, and it starts with mapping instead.

That means enumerating every feature in the product that causes the server to make an outbound request on someone's behalf: webhooks, URL importers, preview generators, third-party integrations, internal service calls. Whitebox access to source code is what makes this enumeration complete; you can grep for HTTP client calls, URL construction logic, and redirect-following configuration directly. Blackbox testing only finds what's visible from the outside, and a lot of fetching logic never surfaces in a UI at all.

From there, a serious assessment runs a specific set of cloud-aware test cases:

• Direct metadata endpoint access, testing both IMDSv1 exposure and IMDSv2 preflight bypass attempts
• Internal VPC endpoint probing to see what the compromised server can reach beyond the metadata service
• Redirect-chain attacks, supplying a URL that redirects to the metadata endpoint to test whether the HTTP client follows redirects without checking the destination
• DNS rebinding, resolving to a benign IP at scan time and rebinding to the metadata IP at fetch time
• Filter bypass variants covering decimal encoding, IPv6 notation, URL fragments, and other alternative representations of 169.254.169.254

Finding the flaw is only half the job. Proving it means producing the exact request, the server's response or an out-of-band confirmation for blind cases, and, when metadata access is involved, the actual credential material returned. That's the line between a real finding and a vague "potential SSRF" flag sitting in a report nobody trusts.

The tester also has to check whether the SSRF chains with something else, an overpermissioned IAM role, weak network segmentation, an internal service with no authentication of its own. SSRF rarely stays a standalone bug; it's the door, and chaining is what shows how far it opens.

None of this replaces human judgment. An experienced tester looking at a potential SSRF finding can tell whether a filter bypass is genuine, whether the IAM role attached makes the finding critical or minor, and whether the remediation advice actually accounts for the cloud environment it's sitting in. That's not a checklist exercise. The SonicWall 2025 Cyber Threat Report recorded a 452% increase in SSRF attacks from 2023 to 2024, driven in part by AI-powered tools generating bypass payloads automatically, and the bar for what counts as "tested" went up rather than staying where it was five years ago.

Remediating SSRF in cloud SaaS — what actually reduces risk versus what just looks like it does

Blocklists feel like a fix, but they're not.

Blocking the string "169.254.169.254" gets bypassed the first week by anyone who tries decimal encoding, IPv6 notation, or a redirect chain that lands there indirectly. Blocklists are a cat-and-mouse game where the attacker always gets to move next. Allowlists are the structural fix: validate that user-supplied URLs match an explicit list of expected domains and schemes, and reject anything that resolves, after DNS resolution, to RFC-1918 or link-local address space. Checking before resolution isn't enough; DNS rebinding exists specifically to slip past that gap.

Enforcing IMDSv2 across every compute instance closes off the simplest credential harvesting path, and this is an infrastructure fix, not an application fix, so it belongs in infrastructure-as-code review, not a developer's backlog ticket.

Least-privilege IAM matters just as much, maybe more. If the instance role only has the permissions the application actually needs, then even a successful SSRF exploit that steals the role token is bounded by what that role can do. Audit and trim these roles as a standing practice after every pentest, not just once during the initial build.

Network-level controls round it out: egress filtering so outbound requests from compute instances can only reach known external destinations, and internal services locked down so they're not reachable from application servers unless there's an explicit, documented reason.

Retesting is the only way to confirm any of this actually worked. A developer telling you the code changed isn't proof; running the same bypass techniques against the same endpoint after the fix is proof instead. And because new URL-fetching features ship constantly in a SaaS product, SSRF-specific checks belong in pull request scanning, catching the regression before it reaches production instead of waiting for next year's test.

Some fixes look like remediation and aren't. Requiring URLs to start with "https://" without also blocking internal addresses does nothing against an attacker who just points at an internal HTTPS endpoint. Logging the outbound request without blocking it tells you what happened after it already happened, and disabling one metadata endpoint path while leaving others reachable just moves the attacker to the door you forgot to lock.

SSRF gets treated like a minor finding because it starts small: a URL field, a webhook, a preview feature. In the cloud, small doesn't stay small, because the infrastructure was built to make identity and access fast and automatic, and that's precisely what an attacker inherits the moment your server fetches a URL it shouldn't.