<\/p>\n
Every feature that makes your server fetch a URL someone else chose is a door into your network. SSRF prevention<\/strong> matters most in the cloud, because that door can lead to the service that hands out your IAM credentials.<\/p>\n Last updated: 2026-11-04. CVE details, cloud documentation and OWASP status below were checked against the primary sources listed at the end on that date.<\/em><\/p>\n Key takeaways<\/strong><\/p>\n According to OWASP Top 10 2021 (A10)<\/a>, SSRF happens when an app fetches a remote resource from a user-supplied URL without validating it. The server then sends requests to destinations the attacker chooses, including ones the attacker could never reach directly.<\/p>\n Where it sits in the OWASP lists has changed. SSRF entered in 2021 as A10, added from the community survey, and OWASP noted its incidence rate was relatively low. In the 2025 edition<\/a> there is no standalone category. CWE-918 (SSRF) is mapped into A01:2025 Broken Access Control. It was merged, not removed.<\/p>\n The cloud raises the stakes. On AWS, GCP and Azure, the instance metadata service sits at the link-local address Look for any place your backend turns a string into an outbound request. The usual sinks:<\/p>\n That is a pattern list from our testing, not a statistic. We have no sourced figure for how many apps have SSRF, and we will not invent one.<\/p>\n Three published CVEs show that your own validation is not the only place this breaks:<\/p>\n The lesson is ours: a This is the mechanism, without payloads. A cloud VM gets temporary credentials for its IAM role from the metadata service. Whatever that role is allowed to do, anyone who can make the server query the service can do. The blast radius equals the role.<\/p>\n AWS has two versions of the service. According to the EC2 User Guide<\/a>, IMDSv1 answers a plain GET. IMDSv2 requires a session token, obtained with a The AWS Security Blog<\/a> (19 November 2019) says IMDSv2 “protects against the vast majority of SSRF vulnerabilities”. Note the wording: the vast majority, not all. IMDSv2 also refuses token requests that carry an The other clouds use a similar idea. Google Cloud<\/a> requires a One caveat applies to all of them. AWS notes that a static header requirement is weaker against SSRF bugs that let an attacker set arbitrary headers. These controls stop the simple GET-only case. They are not a reason to skip the other layers.<\/p>\n Most first attempts at SSRF prevention check the URL string. Blocklist A hostname can resolve to a public IP when you check it and an internal IP when you connect. The OWASP cheat sheet is explicit that a domain allowlist alone does not prevent DNS rebinding. Validate the resolved<\/em> IPs, then connect only to those IPs, including on retries and fallbacks. OWASP A10 also warns: “Be aware of the URL consistency to avoid attacks such as DNS rebinding” and TOCTOU races.<\/p>\n A URL that passes your check can answer with a redirect to somewhere that would not. OWASP says to disable redirects. Check your HTTP client’s defaults: per the Requests documentation<\/a>, Python Addresses can be written in hex, octal, dword and mixed forms, and IPv4 and IPv6 handling differs between libraries. String checks miss these. The cheat sheet advises parsing with a vetted library, comparing the parsed output, and rejecting the URL if parsers disagree on the host.<\/p>\n AWS also offers an IPv6 metadata endpoint, OWASP’s position is that deny-lists are bypass-prone and allow-lists are preferred. Build the outbound URL yourself where you can, and do not accept full URLs from users.<\/p>\n The same flaw shows up in AI products. CVE-2023-46229<\/a> affected LangChain before 0.0.317. Its Our analysis, not an industry finding: a “browse” or “fetch URL” tool, a RAG ingester and a document loader are all SSRF sinks. The URL can come from a user, from a crawled page, or from model output. Treat every one of them as untrusted input.<\/p>\n An attacker can steer which URL an agent fetches. That steering is covered in our post on prompt injection.<\/p>\n Our recommendation, consistent with the OWASP guidance: run fetch tools in a sandbox or an egress-restricted network with no cloud role, and apply the same resolved-IP checks to them as to any other sink.<\/p>\n The default metadata hop limit on EC2 is 1, which AWS says is “to prevent IP forwarding”.<\/p>\n According to the Amazon EKS Best Practices guide<\/a>, eksctl and the official EKS CloudFormation templates set the hop limit to 2 and enable both IMDSv1 and IMDSv2. Pods can then inherit the node’s instance-profile permissions. EKS guidance is to require IMDSv2 and set hop count 1 to block pods that do not need access, without disabling IMDS on the nodes.<\/p>\n AWS recommends hop limit 2 for containers that genuinely need IMDS. The trade-off is that an SSRF inside such a container can reach IMDS too. The better answer is EKS Pod Identity or IRSA, so pods never need the node role. Hop limit 1 is not universally right. It breaks containers that legitimately depend on IMDS.<\/p>\n This is the core of layer three below. It is conceptual, for Python 3.11 or later. It rejects non-HTTPS URLs, credentials in the URL, odd ports, and any resolved address that is not public.<\/p>\n This check alone is not enough. Without pinning, your HTTP client does a second DNS lookup when it connects, and that lookup can return a different answer. Pinning the validated IPs is what closes the rebinding gap. It needs a custom transport or an egress proxy.<\/p>\n This is the order we would work through it. Each step lists its cost.<\/p>\n On step 5, be careful with what AWS defaults actually did. According to the AWS News Blog<\/a> (6 November 2023), defaults changed for new launches and new instance types, and IMDSv1 can still be enabled. Existing instances are not migrated. Check yours.<\/p>\n\n
What is SSRF, and why does the cloud make it worse?<\/h2>\n
169.254.169.254<\/code> and is reachable only from the instance itself. A server-side fetch is a request from the instance<\/em>. The OWASP SSRF Prevention Cheat Sheet<\/a> names metadata services as a common SSRF target for credential theft.<\/p>\nWhere server-side request forgery hides in a startup stack<\/h2>\n
\n
jku<\/code> and x5u<\/code> headers, which make your server fetch a key from a URL the token supplies (we cover that in our JWT vulnerabilities guide<\/a>)<\/li>\n<\/ul>\nFrameworks and HTTP clients get it wrong too<\/h3>\n
\n
Host<\/code> header can cause SSRF when the app is self-hosted, uses Server Actions and redirects to a relative path. Fixed in 14.1.1. NVD scores it 7.5 (CVSS 3.1).<\/li>\nbaseURL<\/code>, leading to “SSRF and credential leakage”. Fixed in 1.8.2. NVD scores it 5.3 (CVSS 3.1). The GitHub CNA scores it 7.7 (CVSS 4.0).<\/li>\nbaseURL<\/code> or a hardcoded prefix is not a security boundary. Patch the versions above, then keep validating.<\/p>\nHow a URL fetch becomes cloud credentials<\/h2>\n
PUT<\/code> request and then sent as a header on later requests. A simple “fetch this URL” bug that can only send a GET cannot complete that handshake.<\/p>\nX-Forwarded-For<\/code> header, and the token response’s IP TTL defaults to 1 so it does not leave the instance.<\/p>\nMetadata-Flavor: Google<\/code> header and rejects requests with X-Forwarded-For<\/code>. Azure<\/a> requires Metadata: true<\/code> and also rejects X-Forwarded-For<\/code>.<\/p>\nWhy URL filtering fails<\/h2>\n
localhost<\/code>, block 169.254.169.254<\/code>, done. It does not work, for five reasons.<\/p>\nDNS rebinding and time-of-check races<\/h3>\n
Redirects<\/h3>\n
requests<\/code> follows redirects by default for every verb except HEAD, so pass allow_redirects=False<\/code>.<\/p>\nIP encodings and parser gaps<\/h3>\n
The IPv6 metadata endpoint<\/h3>\n
[fd00:ec2::254]<\/code>. It is off by default and available on Nitro instances only. If it is enabled, a blocklist that covers only the IPv4 address misses it.<\/p>\nDeny-lists in general<\/h3>\n
AI features and agents: SSRF with a language-model front end<\/h2>\n
recursive_url_loader<\/code> allowed SSRF because “crawling can proceed from an external server to an internal server”. NVD scores it 8.8.<\/p>\nContainers and Kubernetes: the hop-limit trade-off<\/h2>\n
A defensive resolve-and-validate check<\/h2>\n
import ipaddress, socket\nfrom urllib.parse import urlsplit\n\ndef resolve_public_ips(url: str) -> list[str]:\n \"\"\"Reject non-https, credentials-in-URL, odd ports, and any non-public resolved IP.\"\"\"\n u = urlsplit(url)\n if u.scheme != \"https\" or not u.hostname or u.username or u.password:\n raise ValueError(\"blocked: scheme\/host\/userinfo\")\n if u.port not in (None, 443):\n raise ValueError(\"blocked: port\")\n ips = {ai[4][0] for ai in socket.getaddrinfo(u.hostname, 443, proto=socket.IPPROTO_TCP)}\n for ip in ips:\n if not ipaddress.ip_address(ip.split(\"%\")[0]).is_global: # drops 169.254\/16, RFC1918, loopback, fc00::\/7\n raise ValueError(\"blocked: non-public destination\")\n return sorted(ips)\n\n# Then connect ONLY to these IPs (pin them in your HTTP transport or egress proxy),\n# send the original Host\/SNI, set allow_redirects=False, a timeout, and a response size cap.\n# Never return the raw upstream response to the user.<\/code><\/pre>\nSSRF prevention checklist, in priority order<\/h2>\n
\n
HttpTokens=required<\/code>), enforce it, and use hop limit 1 unless containers need 2. Trade-off: old SDKs or agents that only speak IMDSv1 will break, so audit them first.<\/li>\nHow long this has been known<\/h2>\n