Applications increasingly fetch remote resources on behalf of users—loading URLs, rendering previews, processing webhooks, importing files, validating links, or integrating with third-party APIs. When those outbound requests are not tightly controlled, attackers can manipulate the server into making arbitrary network requests.
CWE-918 occurs when software retrieves a URL or network resource specified by an attacker without properly restricting the destination or behavior of the request.
In practical terms:
The application lets attackers make the server send requests to unintended internal or external targets.
This article breaks down how SSRF works, why developers still get it wrong, modern exploitation techniques, framework-specific mitigations, and secure coding patterns.
What Is Server-Side Request Forgery?
SSRF happens when an attacker can influence a server-side request to arbitrary destinations.
Unsafe example:
url = request.args["url"]
response = requests.get(url)
If the application fetches any attacker-supplied URL, the attacker may direct the server to:
- Internal admin panels
- Cloud metadata services
- Internal APIs
- Databases / Redis / memcached
- Localhost-only services
- Third-party targets for abuse
How SSRF Actually Works
The core issue is trusting attacker-controlled destinations for outbound requests.
Attack Flow
- Application accepts URL / host / endpoint input
- Server makes outbound request using supplied value
- Attacker points request to internal/sensitive target
- Server accesses target on attacker’s behalf
- Response or side effects aid compromise
Visual: SSRF Request Flow
Why Developers Still Get SSRF Wrong
URL Fetching Feels Harmless
Developers treat outbound requests as utility features, not security boundaries.
Partial Validation Only
Checks validate:
- URL format
- Protocol presence
- Domain substring
…but fail to restrict true destination.
DNS Is Trusted Too Much
Validation happens before DNS resolution changes.
Internal Network Assumptions
Developers assume internal services are unreachable externally.
Cloud Metadata Blind Spots
Developers forget instance metadata endpoints exist.
Modern Exploitation Techniques
Cloud Credential Theft
Target metadata services such as:
- AWS IMDS
- Azure IMDS
- GCP Metadata Server
Internal Network Scanning
Probe internal hosts/ports through timing/response differences.
Blind SSRF
Exploit without seeing response directly.
DNS Rebinding
Pass validation, then resolve to internal IP later.
Protocol Smuggling / Alternate Schemes
Abuse protocols like:
gopher://file://dict://- Custom handlers
Visual: SSRF Exploitation Chain
Framework-Specific Mitigations
Prefer Allowlisting Over Free-Form URLs
Unsafe:
fetch(user_url)
Safer:
if hostname in APPROVED_HOSTS:
fetch(url)
Validate After DNS Resolution
Check resolved IP, not just hostname.
Block Internal / Reserved Address Ranges
Reject destinations in:
127.0.0.0/8- RFC1918 private ranges
- Link-local ranges
- Metadata service IPs
Restrict Protocols
Allow only expected schemes:
https://http://(if necessary)
Reject dangerous alternate protocols.
Secure Coding Examples
Unsafe
axios.get(req.body.url);
Safer
const parsed = new URL(req.body.url);
if (!ALLOWED_HOSTS.includes(parsed.hostname)) reject();
Better
Use backend-managed identifiers instead of raw URLs:
fetch_partner_resource(partner_id)
Map trusted IDs to known endpoints server-side.
Defense in Depth
Segment Network Access
Application servers should not freely reach sensitive internal services.
Protect Metadata Services
Require IMDSv2 / metadata hardening where supported.
Monitor Outbound Traffic
Unexpected outbound connections may indicate SSRF exploitation.
Threat Model All URL Fetching Features
Common SSRF sources include:
- Webhook validation
- URL previews
- Import/export tools
- PDF renderers
- Image fetchers
- SSO/OpenID integrations
Final Thoughts
SSRF is dangerous because it converts your infrastructure into an attacker-controlled network client.
It persists because:
- Outbound requests are treated as low risk
- Destination validation is deceptively hard
- Internal trust assumptions remain widespread
- Cloud-native environments expand impact dramatically
The core lesson is simple:
If attackers control where your server sends requests, they control part of your network trust boundary.
Every outbound request feature must be treated as a potential pivot point into internal infrastructure.
2 thoughts on “CWE-918: Server-Side Request Forgery (SSRF) — When Attackers Turn Your Server Into Their Proxy”