SSRF - Server-Side Request Forgery
Most vulnerabilities let attackers talk to the server.
SSRF lets them make the server talk on their behalf.
It’s not about breaking the server directly.
It’s about convincing it to reach out, blindly, to places it was never meant to go.
What this page covers
- What SSRF is: the concept, the mechanics, and the impact
- How to exploit it: payloads, targets, and real-world examples
- How to defend against it: validation, isolation, and network design
- How to detect it: signs, logs, and behavioral patterns
- How I’ve practiced it: labs, notes, and internal recon experiments
This isn’t just about sending requests.
It’s about abusing trust and reach, using the server as a proxy for exploration and attack.
What SSRF Actually Is
Server-Side Request Forgery (SSRF) is a vulnerability
that allows an attacker to make the server send
HTTP or other protocol requests to arbitrary destinations.
The attacker controls the destination,
and sometimes the method, headers, or body of the request.
The Core Idea:
An application accepts a user-supplied URL or address and fetches it server-side, without properly validating or restricting where it can go.
Common Examples
- Image preview or URL fetchers that accept external links
- PDF generators that load remote assets
- Webhooks or integrations that accept callback URLs
- Internal API calls triggered by user input
- Cloud metadata services exposed at
http://169.254.169.254
SSRF is often found in:
- Microservices architectures
- Cloud environments
- Internal dashboards
- Third-party integrations
What Happens When It’s Exploited
- Accessing internal services not exposed to the public
- Reading cloud metadata (AWS, Azure, GCP) to extract credentials
- Port scanning internal networks from the server
- Bypassing firewalls and network segmentation
- Triggering secondary vulnerabilities in internal endpoints
SSRF turns the server into a reconnaissance tool.
It’s not just about what the attacker can reach, but what the server can.
How to Mitigate SSRF
1. Validate and Sanitize URLs
Reject user-supplied URLs that point to internal IP ranges or loopback addresses.
Use allowlists instead of denylists.
2. Isolate Network Zones
Place servers that handle external requests in tightly restricted network segments.
Limit their ability to reach internal services.
3. Use DNS Resolution Safeguards
Prevent DNS rebinding and manipulation.
Resolve and verify hostnames before making requests.
4. Monitor Outbound Requests
Log and alert on unusual outbound traffic patterns.
Use egress filtering to block unauthorized destinations.
5. Disable Unnecessary Protocols
If the application only needs HTTP, block access to FTP, Gopher, file, or other schemes.
Mitigation is about controlling what the server can talk to, and making sure it doesn’t speak out of turn.
How I Practice SSRF
I use labs like:
- Hack The Box: Academy and challenges
- PortSwigger Web Security Academy
- TryHackMe: SSRF playgrounds
- Juice Shop and custom apps in my homelab
I test:
- External URLs and redirection tricks
- Internal IP ranges (127.0.0.1, 10.0.0.0/8, 169.254.169.254)
- Header injection and method manipulation
- DNS rebinding and host resolution quirks
- Chained SSRF leading to RCE or credential theft
Every SSRF attempt teaches me something about how servers trust their own network — and how that trust can be abused.
Final Thought
SSRF is quiet.
It doesn’t scream in logs or crash systems.
It just reaches out, politely, to places it should never go.
This page is my study of that reach.
Not just how to exploit it, but how to understand it, contain it, and explain why it matters.