25 min read, Understand how SSRF works, why cloud environments make it more dangerous, how attackers can abuse internal network access and cloud metadata, and how to defend against SSRF using URL validation, network segmentation, least-privilege IAM, metadata protection, and outbound traffic controls.
From the journal
A web application may appear to be exposed only to the public internet.
But behind that application could be a completely different world:
Internal APIs
Databases
Cloud metadata services
Message queues
Admin panels
Monitoring systems
Private network services
This is where Server-Side Request Forgery (SSRF) becomes particularly dangerous.
An SSRF vulnerability can allow an attacker to make your server send requests to destinations the attacker cannot directly access.
In a traditional environment, that might mean reaching an internal service.
In a cloud environment, it can potentially become much more serious—because the server may also have access to cloud control-plane services, instance metadata, temporary credentials, and other resources inside the private network.
What Is SSRF?
Server-Side Request Forgery (SSRF) is a vulnerability where an attacker manipulates a server into making a network request on their behalf.
Imagine an application with a URL preview feature:
POST /preview
{
"url": "https://example.com/image.jpg"
}
The server fetches the supplied URL and returns information about the resource.
That seems harmless.
But what happens if an attacker supplies a URL pointing somewhere that should never be accessible from the public internet?
Conceptually:
Attacker
│
│ malicious URL
▼
Web Application
│
│ server-side request
▼
Internal Service
The attacker doesn't directly access the internal service.
Your server does it for them.
That is the core of SSRF.
Why SSRF Becomes More Dangerous in the Cloud
Cloud environments fundamentally change the impact of SSRF.
A cloud-hosted application may have network access to resources that are intentionally hidden from the public internet.
For example:
Internet
│
▼
┌─────────────┐
│ Web Server │
└──────┬──────┘
│
┌─────────┼─────────┐
▼ ▼ ▼
Internal API Database Queue
│
▼
Cloud Metadata
If the web server can reach those resources, an SSRF vulnerability may provide an attacker with a new path into your infrastructure.
The vulnerability is no longer simply:
"The application can fetch an unexpected URL."
It can become:
"The attacker can make my server communicate with systems that trust my server."
The SSRF Attack Flow
A typical cloud SSRF attack can be thought of as five stages.
1. Find a Server-Side Request Feature
Attackers look for functionality such as:
URL previews
Image importers
Webhooks
PDF generators
URL scanners
Remote file import
Proxy functionality
API integrations
Link unfurling
Anything that causes your server to make an outbound request can potentially deserve scrutiny.
2. Manipulate the Destination
Instead of requesting a normal public resource, the attacker attempts to make the application contact an internal destination.
The important point isn't the exact payload.
The important concept is:
User-controlled URL
↓
Server-side HTTP client
↓
Unexpected destination
3. Reach the Private Network
If the server can communicate with private network resources, the attacker may be able to interact with services that aren't directly exposed to the internet.
Potential targets include:
Internal REST APIs
Databases
Kubernetes services
Message brokers
Monitoring dashboards
Administrative interfaces
4. Access Cloud Metadata
Cloud platforms provide metadata services that can expose information about compute instances and their environment.
Historically, cloud metadata endpoints have been an important SSRF target.
For example, AWS's instance metadata service uses the link-local address:
169.254.169.254
If an application can improperly access metadata and the environment is configured unsafely, an attacker may potentially obtain information or credentials associated with the workload.
Modern cloud environments provide protections against this, but developers should still treat metadata access as a high-risk boundary.
5. Turn Access Into Impact
The final impact depends on what the compromised workload can access.
Potential consequences include:
Credential theft
Unauthorized API calls
Access to internal services
Data exposure
Lateral movement
Cloud resource modification
Privilege escalation
This is why SSRF should not be treated as merely an HTTP validation bug.
Cloud Metadata: The High-Value Target
One reason cloud SSRF receives so much attention is the instance metadata service.
Cloud compute instances can use metadata services to retrieve information about their environment.
In some configurations, metadata can also be associated with temporary credentials.
If an attacker can abuse SSRF to reach a metadata service and retrieve usable credentials, the attack can potentially move beyond the compromised web application.
The chain can become:
SSRF
↓
Metadata Service
↓
Temporary Credentials
↓
Cloud API
↓
Additional Resources
This is why identity permissions and network controls are both critical.
AWS IMDSv2 and SSRF
AWS provides Instance Metadata Service Version 2 (IMDSv2), which introduces a session-oriented mechanism that makes many common SSRF-based metadata attacks harder.
The important security lesson isn't simply:
"Enable IMDSv2."
It is:
Don't rely on one control to solve SSRF.
Applications should still validate outbound requests, restrict network access, use least-privilege IAM roles, and monitor suspicious behavior.
Defense should be layered.
Common SSRF Entry Points
SSRF can hide inside features that don't initially look dangerous.
URL Previewers
Applications that generate previews from user-supplied URLs need to fetch remote resources.
That creates an outbound request boundary.
Image Importers
Consider:
"Paste an image URL and we'll import it."
The server has to retrieve the image.
If destination validation is weak, the feature may become an SSRF entry point.
Webhooks
Applications often allow users to specify:
https://example.com/webhook
The server later sends requests to that destination.
Webhook systems therefore need strong destination controls.
PDF and Document Generators
A server-side renderer may retrieve:
Images
CSS
Fonts
External resources
If those resources can be controlled by an attacker, the renderer can potentially become an SSRF primitive.
File Importers
Features such as:
"Import a file from URL"
should be treated carefully.
The server is effectively acting as a network client controlled by user input.
SSRF Can Reach More Than Metadata
Cloud metadata gets most of the attention, but it isn't the only concern.
An SSRF-capable application may potentially reach:
Internal APIs
10.x.x.x
172.16.x.x
192.168.x.x
Databases
For example:
PostgreSQL
MySQL
Redis
MongoDB
Message Brokers
Such as:
RabbitMQ
Kafka
Internal queue services
Administration Interfaces
For example:
Monitoring dashboards
Internal management panels
Development tools
Service administration APIs
Container and Orchestration Infrastructure
Cloud-native applications may have additional internal services associated with:
Kubernetes
Container platforms
Service meshes
Internal control-plane components
The risk depends heavily on network architecture and access controls.
Why Network Segmentation Matters
Suppose your application server can communicate with everything inside the VPC.
An SSRF vulnerability becomes significantly more valuable to an attacker.
Instead, design networks so that applications can only reach what they actually need.
For example:
Internet
│
▼
Load Balancer
│
▼
Web Application
│
┌─────┴─────┐
▼ ▼
API Service Database
The web application shouldn't automatically have unrestricted access to every internal system.
Network segmentation reduces the blast radius.
The Most Important Defense: Validate Destinations
The strongest general defense is to avoid treating user-supplied URLs as inherently trustworthy.
Instead of:
User URL → HTTP Client → Internet
use:
User URL
↓
Parse
↓
Validate
↓
Resolve
↓
Apply network policy
↓
Request
Validation should consider:
Allowed schemes
Allowed hosts
Allowed ports
DNS resolution
IP address ranges
Redirect destinations
Private addresses
Link-local addresses
Loopback addresses
And validation needs to account for DNS rebinding and redirect-based bypasses rather than checking only the initial URL string.
Prefer Allowlisting Over Blocklisting
A common mistake is attempting to block a list of dangerous destinations:
Block:
127.0.0.1
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
That can be useful as one layer, but it isn't sufficient by itself.
Attackers can exploit:
Alternate IP representations
DNS resolution tricks
Redirects
IPv6
Rebinding
Parser inconsistencies
Proxy behavior
Whenever possible, ask:
Which destinations does this feature actually need to access?
Then allow only those destinations.
An allowlist is generally easier to reason about than trying to enumerate every dangerous destination.
Use Network-Level Controls
Application-level validation should be combined with network controls.
Consider restricting outbound traffic using:
Security groups
Network ACLs
Firewalls
Egress proxies
Service-to-service policies
Kubernetes network policies
If an application doesn't need to communicate with a database directly, the network shouldn't allow it to.
This creates defense in depth.
Use Least-Privilege Cloud IAM
Even if SSRF occurs, the attacker's potential impact should be limited.
Your application shouldn't have permissions like:
*
*
*
unless there is an exceptional and carefully justified reason.
Instead, give workloads only the permissions they require.
For example:
Application
↓
IAM Role
↓
Read-only access
↓
Specific storage resources
If credentials are compromised, least privilege limits what the attacker can do with them.
Protect Cloud Metadata Services
Cloud providers offer specific controls for protecting metadata services.
For AWS workloads, IMDSv2 should be strongly considered and enforced where appropriate.
Also consider:
Restricting metadata access
Preventing unnecessary metadata exposure
Using least-privilege instance roles
Monitoring metadata access
Separating workloads with different trust levels
Metadata should never be treated as an ordinary public HTTP endpoint.
Monitor Outbound Requests
Most security monitoring focuses heavily on inbound traffic.
SSRF reminds us that outbound traffic matters too.
Monitor for unusual connections to:
Private IP ranges
Link-local addresses
Metadata endpoints
Internal administrative ports
Unexpected domains
Rare destinations
Previously unseen services
An application that normally communicates with three external APIs suddenly communicating with an internal management service should raise suspicion.
SSRF Prevention Checklist
Before shipping a feature that makes server-side requests, ask:
Is the destination controlled by the user?
Do we actually need arbitrary URLs?
Can we use an allowlist?
Are only required URL schemes allowed?
Are redirects validated?
Are DNS results validated?
Are private and link-local destinations blocked where appropriate?
Can the application reach cloud metadata?
Is outbound network traffic restricted?
Are cloud IAM permissions minimal?
Is IMDSv2 enabled where applicable?
Are outbound requests logged and monitored?
A Secure Architecture Mindset
The biggest lesson from SSRF is that network reachability is a security boundary.
A web server doesn't need to be able to reach everything just because it technically can.
Instead, design your infrastructure around explicit trust relationships:
Internet
│
▼
Load Balancer
│
▼
Web Application
│
├──→ Approved External API
│
└──→ Required Internal Service
X
│
├── Metadata
├── Database Admin
├── Internal Dashboard
└── Unnecessary Services
The fewer places your application can communicate with, the less useful an SSRF vulnerability becomes.
Final Thoughts
SSRF can look deceptively simple.
At first glance, it may appear to be nothing more than:
"The server fetches a URL it shouldn't."
But cloud environments change the equation.
That server may have access to private networks, internal APIs, cloud metadata, temporary credentials, and powerful cloud identities.
An attacker doesn't necessarily need direct access to those resources.
They may only need to convince your server to access them.
That's why SSRF defense requires more than filtering a URL.
You need multiple layers:
Validate destinations. Restrict outbound traffic. Protect metadata. Minimize cloud permissions. Segment networks. Monitor server-side requests.
In a cloud environment, your application's ability to make outbound requests is itself a security boundary.
Control where your server can go—and you dramatically reduce where an attacker can go through it.
Have a related challenge in mind?
Start a conversation