Server-side request forgery is a critical vulnerability where a threat actor manipulates a server into making HTTP requests on their behalf, often to internal, non-public services.
Because the server typically trusts its own environment, attackers are able to pass maliciously crafted URLs through, exposing internal APIs, metadata services, or other sensitive data. Given that SSRF can happen even when systems sit behind a VPN, firewall, or a network access control list (ACL), SSRF was added to the OWASP Top 10 in 2021, and it ranks among MITRE’s CWE Top 25 Most Dangerous Software Weaknesses.
On the surface, SSRF looks like a simple proxy of user-provided URLs. In reality, it’s an entry point into cloud metadata endpoints and private network resources, making it a dangerous vulnerability, especially in cloud and microservices architectures. Apart from unauthorized access to sensitive system data, several other adverse impacts include internal port scanning and exploit chaining into other attacks (for example, remote code execution and reflected XSS). SSRF is a major reason why continuous API visibility and URL validation are mission-critical.
In this article, we’ll explore how to detect and prevent SSRF attacks. But first, it’s essential to understand how an SSRF attack works and exactly where the risk lies.
Advanced API Security Best Practices [Cheat Sheet]
Download the Wiz API Security Best Practices Cheat Sheet and fortify your API infrastructure with proven, advanced techniques tailored for secure, high-performance API management.
How SSRF attacks work: An example
Applications with features that accept a user-provided URL and fetch it server-side are classic targets of SSRF. (Image previews, link unfurling, web-to-PDF services, and metadata fetchers are just a few examples). If the server blindly follows redirects or doesn’t restrict destinations, then an attacker can direct the server to internal addresses, link-local cloud metadata hosts, and IPv6 local/ULA ranges.
For instance, the Express.js route handler below fetches any URL provided by the user. Because it runs within the application’s trust boundary, it can access networks and services that an attacker cannot directly reach. An SSRF attack occurs when a malicious user supplies a URL such as http://127.0.0.1:8080/metrics, causing the server to request internal data and return it to the attacker:
app.get("/proxy", async (req, res) => {
const target = req.query.url;
const resp = await fetch(target, { redirect: "follow" });
const body = await resp.text();
res.type(resp.headers.get("content-type") || "text/plain").send(body);
});In API-centric systems, the risk of SSRF is higher when endpoints allow dynamic URL input without proper validation:
APIs that generate image or video previewers from links provided by users
File upload handlers that accept remote URLs
Webhook processors and third-party integration fetchers that call arbitrary URLs
These ultimately act as open proxies within the trust boundary of the system.
Common SSRF payloads
There are several predictable SSRF payloads that point towards metadata services and internal-only endpoints. Some common examples that are often targeted by attackers include:
http://169.254.169.254/latest/meta-data/:This is the AWS EC2 instance metadata service, a well-known target because it leaks IAM role credentials. Similar endpoints exist in GCP and Azure as well.http://localhost/admin:Applications often have local-only admin panels that are not meant to be accessed externally but can be reached through SSRF.http://internal-service.local/api/keys:Internal microservices may expose sensitive APIs that become reachable if SSRF allows internal network traversal.Redirection chains (e.g.,
http://evil.com/redirect?url=http://localhost): Attackers abuse open redirects to pivot from a benign domain into private/internal targets.
Inside the vault: how financial institutions protect their cloud environments
En savoir plus
Why SSRF is especially dangerous in the cloud
When risk factors like public exposure, weak or missing authorization, excessive permissions, and proximity to sensitive data coexist in cloud environments, they form a toxic combination. The result? High-impact SSRF vulnerabilities.
Unfortunately, these vulnerabilities can easily slip under your radar: When AWS IMDSv1 (Instance Metadata Service v1) is enabled, a server-side fetch to the instance metadata endpoint can return temporary role credentials. Enforce IMDSv2 (HttpTokens=required) and set HttpPutResponseHopLimit appropriately—AWS recommends 2 for containerized environments to avoid breakage through NAT paths; use 1 only when you’ve verified workloads still function. This configuration significantly reduces SSRF impact, especially when the SSRF primitive cannot send PUT requests or custom headers. Source: AWS EC2 User Guide
The Capital One breach in 2019 is a key example of how SSRF can be exploited to escalate from an initial misconfiguration to a large-scale data breach. The entry point of this attack path was a misconfigured web application firewall (WAF) on an EC2 instance. After gaining access, threat actors used an SSRF attack to obtain temporary IAM role credentials by making requests to the AWS metadata service. The IAM role they leveraged had excessive permissions and access to S3 buckets, resulting in a massive data breach: The attackers listed and exfiltrated nearly 30 GB of credit application data, which included more than 100 million Capital One customers’ extremely sensitive PII (think Social Security numbers and credit scores).
The big takeaway? The cloud amplifies the impact of SSRF. Today, these attacks are faster and more damaging than ever, making detection and prevention a top priority. Context that links public exposure, identity permissions, data sensitivity, and runtime behavior is crucial to prioritize SSRF risks that form toxic combinations.
SSRF detection and prevention: Best practices for cloud applications
The best practices discussed below are great for stopping SSRF attacks from bridging the gap between insecure public endpoints and sensitive internal systems, but remember: Detection and prevention mechanisms should be treated as an ongoing process. Tying detections and controls back to owners – code, pipeline, service, and data – accelerates remediation and reduces MTTR.
Detection methods
Monitor outbound traffic for anomalies: Track egress requests from workloads and APIs to private and internal IP ranges (e.g.,
RFC1918, 127.0.0.0/8), link-local addresses (including cloud metadata IPs such as AWS169.254.169.254andIPv6 [fd00:ec2::254]), and IPv6 local ranges (e.g.,::1/128 loopback). Set alerts to trigger if these requests originate from services that don’t normally require access to private or metadata endpoints.Detect suspicious redirect chains: Attackers abuse whitelisted URLs that issue a 301/302 redirect to an internal target. To keep this from happening, maintain full visibility into HTTP requests and their redirects and flag redirect chains where the final hop resolves to a private or metadata IP.
Leverage runtime request sampling: Periodically capture outbound HTTP requests, including full URLs and headers, to spot suspicious destinations during routine operations.
Open-source tools like SSRFire and ZAP can actively test for SSRF injection points and help validate payload routing and out-of-band callbacks; they are not designed to monitor runtime traffic for anomalies.
What Is Cross-Site Request Forgery (CSRF)? Examples, Vulnerabilities, and Prevention
Cross-site request forgery (CSRF), also known as XSRF or session riding, is an attack approach where threat actors trick trusted users of an application into performing unintended actions.
En savoir plus
Prevention methods
Use this actionable checklist to jumpstart your SSRF prevention strategy:
1. Input validation
Parse and normalize URLs before processing. Avoid relying solely on regex; enforce scheme allowlists, canonicalize hostnames, and re-resolve DNS on every redirect hop. Instead, use URL parsing libraries that normalize and validate input against an allowlist of approved schemes (e.g., http, https) and explicitly reject dangerous schemes such as
file://, gopher://, or ftp://.Enforce strict allowlists of permitted hostnames or domains for features that fetch remote content. Resolve hostnames to IPs at validation time and verify they fall within the allowlist to block DNS rebinding attacks.
Reject unused URL schemes (
file://, gopher://, ftp://, dict://, custom handlers). It’s safest to allow only HTTP and HTTPS until a use case for accepting other URL schemes comes up.Block destinations that resolve to loopback, private, link-local, or metadata addresses. Apply these checks on initial resolution, on redirects, and at connect time.
2. Network-level controls
Deny unnecessary egress by default. Block outbound traffic to private and local ranges unless explicitly required. Cover
IPv4 127/8, 10/8, 172.16/12, 192.168/16, 169.254/16 and IPv6 ::1/128, fc00::/7, fe80::/10. Enforce these controls at egress gateways/NAT/proxies for routable traffic.Restrict access to metadata services. Treat metadata endpoints as link-local and block access with host- or node-level controls. In Kubernetes, apply CNI egress policies for pods that don’t require metadata. Ensure both
IPv4andIPv6 IMDSendpoints are blocked per the cloud provider’s current documentation. Source: AWS EC2 User Guide.Implement egress allowlists for outbound HTTP/HTTPS traffic, scoped to required destinations, to prevent data exfiltration to external networks if an attack occurs.
In Kubernetes, use NetworkPolicies to deny egress by default, block both
IPv4andIPv6metadata endpoints cluster-wide, prefer IRSA (IAM Roles for Service Accounts) or Workload Identity over node metadata, and consider a mesh egress gateway for domain allowlists and TLS enforcement.
3. Cloud-native defenses
Use IMDSv2 with AWS. Enforce hop limits, require session-based tokens, and disable less secure IMDSv1 entirely if it was used previously.
Incorporate best practices when using Azure Instance Metadata Service (IMDS). Specify API version, add the required Metadata: true header, obtain managed identity access tokens, and minimize assigned permissions.
For GCP, enable Workload Identity and ensure requests include the Metadata-Flavor: Google header; avoid long-lived service account keys and scope runtime identities minimally.
Limit token lifetimes and permissions because SSRF payloads often aim to capture these tokens before they’re rotated.
Disable unused cloud services at the account/project level to minimize your attack surface and shrink reachable targets.
4. API-specific controls
Identify and document shadow APIs to ensure they’re governed and monitored.
Enforce authentication and token validation for all endpoints. Also remember to scan for authorization misconfigurations in JWT tokens.
Continuously monitor API request patterns for anomalies such as spikes in URL parameters and API calls to unapproved domains.
Apply least-privilege IAM roles to API workloads to ensure that a single SSRF compromise doesn’t grant broad lateral movement.
Maintain an accurate, up-to-date API inventory to gain full visibility, eliminate blind spots, and quickly assess exposure during incidents.
Prevention isn’t about a single type of control. It’s a combination of tight input sanitization and validation, network monitoring and segmentation, and continuous API governance. A unified policy engine that spans code, CI/CD, cloud, and runtime ensures SSRF defenses remain consistent as services evolve.
Using runtime-aware tools to implement the practices we’ve discussed enhances coverage and on-time risk discovery. Falco, ZAP, and Burp Suite provide runtime and preproduction scanning capabilities to detect SSRF risks. Better yet? Partner with a platform like Wiz that provides context-driven detection and prevention.
How Wiz helps with API security and SSRF exposure
Most SSRF prevention guidelines assume you know every single API your environment is running. But many organizations are struggling to keep up: Cloud environments evolve fast, making it impossible to update static inventories. Every new deployment comes with new endpoints, and developers sometimes integrate new APIs outside of official processes. As a result, shadow APIs slip into the production environment unnoticed.
Providing total visibility of every API endpoint is where Wiz shines.
Wiz offers a modern approach to API security with purpose-built solutions for cloud environments. Our industry-leading platform…
Automatically discovers all API endpoints and their hosting context
Maps access patterns, sensitive data, and auth misconfigurations
Surfaces toxic combinations like public endpoints fetching internal data
Offers an API Security Dashboard, giving teams a unified view of exposure so that they can cut risk fast—without relying on guesswork or fragmented tools
Ready to get a handle on remediation priorities, reduce your attack surface, and stay ahead of potential threats? Request a personalized demo of Wiz today!
Catch code risks before you deploy
Learn how Wiz Code scans IaC, containers, and pipelines to stop misconfigurations and vulnerabilities before they hit your cloud.
