Server-side request forgery (SSRF) is a critical vulnerability where an attacker manipulates a server into making HTTP requests on their behalf, often to internal, non-public services. Given that SSRF can happen even when systems sit behind a VPN or firewall, it ranks among MITRE’s CWE Top 25 Most Dangerous Software Weaknesses.
How SSRF attacks work
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.
SSRF works by exploiting any feature where a server fetches a URL on behalf of a user, essentially persuading the server to access sensitive data on the attacker's behalf. The attacker substitutes a legitimate external URL with an internal target, and the server dutifully retrieves it.
Get the Application Security Best Practices [Cheat Sheet]
This 6-page guide goes beyond basics — it’s a deep dive into advanced, practical AppSec strategies for developers, security engineers, and DevOps teams.
Consider this Express.js route handler that 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
Attackers target predictable internal endpoints that applications should never reach. Common SSRF payloads include:
Cloud metadata services:
http://169.254.169.254/latest/meta-data/exposes AWS IAM role credentials. GCP and Azure have equivalent endpoints.Internal microservices:
http://internal-service.local/api/keysbecomes reachable when SSRF allows internal network traversal.Redirect chains:
http://evil.com/redirect?url=http://localhostabuses open redirects to pivot from a benign domain into private targets.
Types of SSRF attacks
SSRF attacks fall into the following three categories based on how attackers observe the results.
Standard SSRF
Standard SSRF returns the server's response directly to the attacker. If the vulnerable endpoint echoes fetched content, the attacker sees internal data immediately. This is the easiest variant to detect and exploit.
Blind SSRF
Blind SSRF provides no direct response. Attackers infer success through out-of-band signals like DNS lookups to attacker-controlled servers or timing differences. Blind SSRF is harder to confirm but equally dangerous when it reaches metadata services or internal APIs.
Time-based blind SSRF
Time-based blind SSRF relies on response delays to map internal network topology. Attackers measure how long requests take to determine which hosts and ports are reachable.
Why SSRF is especially dangerous in the cloud
When public exposure, excessive permissions, and proximity to sensitive data coexist in cloud environments, they form a toxic combination. A single SSRF vulnerability becomes the entry point for credential theft, lateral movement, and data exfiltration.
Cloud metadata services are the most dangerous targets. When AWS IMDSv1 is enabled, a server-side fetch to 169.254.169.254 returns temporary IAM role credentials. Enforce IMDSv2 with HttpTokens=required and set HttpPutResponseHopLimit to 2 for containerized environments. This configuration blocks SSRF attacks that cannot send PUT requests or custom headers.
The 2019 Capital One breach 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 identified and exfiltrated nearly 30 GB of credit application data, including extremely sensitive PII for more than 100 million Capital One customers, such as Social Security numbers and credit scores.
The takeaway is that 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 linking public exposure, identity permissions, data sensitivity, and runtime behavior is crucial for prioritizing SSRF risks that form toxic combinations, particularly given that 35% of cloud environments have compute assets that both expose sensitive data and carry critical or high-severity vulnerabilities, according to Wiz’s 2025 Cloud Data Security Report.
SSRF detection and prevention
Stopping SSRF requires controls at multiple layers, including input validation, network segmentation, cloud-native defenses, and API governance. No single control is sufficient because attackers exploit legitimate features like redirects and DNS rebinding rather than bypassing filters directly.
Treat these detection mechanisms as ongoing processes, and tie detections back to code, pipeline, and service owners to accelerate remediation.
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. However, they are not designed to monitor runtime traffic for anomalies.
Cross-Site Request Forgery (CSRF): Examples and Prevention
Discover how CSRF attacks work, identify common vulnerabilities, and learn the best methods for preventing CSRF attacks to keep your applications secure.
더 알아보기
Alongside detection, you also need a prevention strategy. Here are the key components and actionable steps to consider to help get you started.
Input validation
Parse and normalize URLs before processing. Canonicalize hostname and re-resolve DNS on every redirect hop. Use URL parsing libraries that normalize and validate input against an allowlist of approved schemes.
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. According to OWASP, the allowlist approach is preferred over using denylists because denylists are “bypass-prone,” as they only block known malicious inputs.
Explicitly reject dangerous schemes such as
file://,gopher://, orftp://, and block destinations that resolve to loopback, private, link-local, or metadata addresses.
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. Ensure both
IPv4andIPv6 IMDSendpoints are blocked per the cloud provider’s documentation.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.
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. This mechanism is effective against SSRF with a hop limit of 1 and session-oriented tokens.
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.
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.
Maintain an accurate, up-to-date API inventory to gain full visibility, eliminate blind spots, and quickly assess exposure during incidents.
Prevention relies on 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.
Runtime-aware tools like Falco, ZAP, and Burp Suite detect SSRF patterns by monitoring outbound requests and validating app behavior under controlled conditions. But when you combine runtime insights with platform-level context, you can understand how SSRF risks relate to cloud identities, exposed services, and application architecture. Wiz integrates this contextual information into a single view, helping you prioritize SSRF risks based on real impact.
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 Wiz helps with API security and SSRF exposure
SSRF prevention assumes you know every API in your environment, but shadow APIs slip into production faster than static inventories can track. Wiz provides total visibility of every API endpoint, mapping access patterns, sensitive data exposure, and authentication misconfigurations across your cloud environment.
The platform offers a modern approach to API security with purpose-built solutions for cloud environments:
Automatically discover all API endpoints and their hosting context.
Map access patterns, sensitive data, and auth misconfigurations.
Surface toxic combinations like public endpoints fetching internal data.
Access an API Security Dashboard, giving you a unified view of exposure so you can cut risk fast without relying on guesswork or fragmented tools.
Shadow APIs, overprivileged IAM roles, and AI pipelines fetching external data don't appear in static inventories — but they do in breach timelines. Wiz connects the dots between public exposure, cloud identity, and sensitive data so you can see the toxic combinations before attackers do. See it in action with a personalized Wiz demo.
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.
