SSRF, short for server-side request forgery, is a vulnerability in which an attacker manipulates the server application into issuing HTTP (or other protocol) requests toward arbitrary destinations. Those destinations are not chosen by the developer, they are imposed by the attacker through controllable parameters, and they can include internal resources not exposed to the internet, cloud metadata services, systems in the workload's private network, or even non HTTP protocols when the server's HTTP client supports them. In modern architectures, where a legitimate application needs to reach the internet to consume webhooks, third party APIs, or external services, distinguishing a lawful outbound request from an abuse requires explicit control over what the server is allowed to talk to.
The essentials: SSRF turns the server into an involuntary proxy for the attacker. In cloud, its typical impact is the theft of temporary credentials from metadata endpoints (AWS IMDS, Azure IMDS, GCP Metadata), which opens the door to lateral movement with the instance role's permissions. Defense relies on strict allowlisting of destinations, IMDSv2 with hop limit, egress policies, robust URL validation, and workload identity.
What SSRF is and why it matters especially in cloud
SSRF is defined as the ability to induce the server to make network requests toward URLs or hosts that the attacker controls. The application acts as a mediator, performing the connection with its own network credentials and, usually, with visibility to resources the attacker could not reach from outside. That is where the structural risk lies: the server typically sits within a privileged network segment, capable of speaking to internal databases, administration panels, service discovery, or, in cloud, metadata endpoints reachable only from the instance itself.
The difference with CSRF, a vulnerability with a similar name, is radical. CSRF (cross-site request forgery) operates on the client side: the victim's browser sends an authenticated request to a site where it is already signed in, induced by a malicious page. SSRF, in contrast, operates on the server side: the backend component performs the request, with its own credentials and from its own network. That is why CSRF is mitigated with tokens and SameSite cookies, while SSRF requires egress control and destination validation.
In cloud environments, SSRF takes on critical severity because providers expose a metadata endpoint accessible only from within the virtual machine. That endpoint hands out temporary credentials for the role attached to the instance. If the attacker manages to make the application query it on their behalf, they obtain those credentials and can operate against the cloud provider's API with the role's permissions, which frequently translates into bucket reads, function execution, or database access. SSRF stops being a curious redirection and becomes a pivot for cloud compromise.
How a classic SSRF exploit works
The most common real world scenarios start from legitimate features that accept URLs as input. A first example is a URL fetcher, in which the user asks the server to download a remote resource:
POST /api/preview
{ "url": "https://example.com/article" }
The backend runs requests.get(url), then returns or processes the content. If it does not validate the destination, the attacker sends:
{ "url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/" }
and receives the list of IAM roles available on the instance. A second step queries the specific role and receives temporary credentials.
A second scenario is image upload by URL. The application allows uploading an image by providing a URL instead of a file. The server downloads, validates MIME type, and stores. The attacker points that download at an internal HTTP service and, even if the final image is discarded, logs or error messages can leak the internal resource's response.
A third scenario is webhook customizers. A SaaS platform lets the customer register their own URLs to receive notifications. If the server sends the notification immediately from its own network without restricting private destinations, the customer can register an internal endpoint or a metadata endpoint as their webhook and receive its content in their listener.
In all three patterns the mechanics are identical: a URL input controllable by the user, a server side fetch, and the absence of destination validation.
The big SSRF risk in cloud: instance metadata endpoints
Cloud providers expose metadata services reachable from within each instance. These endpoints are legitimate and required for the machine itself to know its configuration and obtain temporary credentials for the assigned role.
On AWS, the endpoint is http://169.254.169.254/latest/meta-data/. IMDSv1 was reachable without a token, which made its exploitation through SSRF straightforward. IMDSv2, introduced in response to observed abuses, requires first obtaining a session token via a PUT request with a specific header, and then using that token in GET requests. That requirement breaks the typical SSRF scenarios based on blind GET.
On Azure, the Instance Metadata Service responds at http://169.254.169.254/metadata/instance and requires the Metadata: true header. That header is trivial to add when the application allows it, but it does block SSRFs based on HTTP clients that do not allow setting arbitrary headers.
GCP exposes the Metadata Server at http://metadata.google.internal/ and requires the Metadata-Flavor: Google header. Same defensive logic as Azure.
Kubernetes adds another dimension. Pods usually have access to the cluster API via the mounted ServiceAccount, as well as to internal services discoverable through internal DNS. An SSRF inside a pod can reach the API server, list namespace secrets, or interact with internal services.
The Capital One incident of 2019 is the best documented public reference for the impact a chained SSRF plus IMDS attack can have. The compromise, officially communicated by the institution, combined access to the metadata service from a vulnerable component with the subsequent use of the obtained credentials to access stored data. Subsequent industry analyses extensively reviewed the attack chain, which has become an archetype of SSRF risk in cloud.
Types of SSRF
Not every SSRF returns the response body to the attacker. The usual operational classification distinguishes several variants.
Basic SSRF returns the response to the client. The attacker directly sees the content downloaded by the server and can read internal endpoints as a conventional proxy.
Blind SSRF, without visible response, does not return content but does execute the request. It is detected and exploited by observing side effects: requests received in an external collaborator controlled by the attacker, log writes, or state changes on the target system. It is the most frequent variant in modern architectures.
Semi-blind SSRF is identified by differences in response time or in error messages depending on the destination and its behavior. It allows inferring whether an internal host exists, whether a port is open, or whether a path returns 200 versus 404, even if content is not visible.
Connection based SSRF exploits only the ability to initiate a TCP connection, without needing a full HTTP protocol. Useful for mapping internal ports through errors and timings.
Finally, some HTTP clients allow additional schemes beyond http:// and https://. Schemes such as file://, gopher://, dict:// or ldap:// greatly expand the attack surface. file:// allows reading files from the server's filesystem. gopher:// has historically been used to send arbitrary traffic to internal services such as Redis or memcached, reaching even remote execution when those services were exposed on localhost without authentication.
Bypass techniques
When the application implements validations, attackers turn to bypass techniques that exploit inconsistencies between the parser that validates and the HTTP client that ultimately connects.
URL parsing inconsistencies are the classic. Different libraries interpret http://attacker.com@169.254.169.254/ or http://169.254.169.254#.attacker.com/ differently. If validation extracts the host with one logic and the HTTP client with another, the bypass happens.
DNS rebinding consists of having an attacker controlled domain resolve first to a public IP (which passes validation) and, on a second DNS lookup moments later, resolve to an internal IP such as 169.254.169.254. Between validation and the actual fetch, the destination has changed.
HTTP redirects can bypass validations that check only the initial URL. The attacker points to a public domain that responds with 302 toward 169.254.169.254. If the client follows redirects without revalidating the destination, the attack succeeds.
IPv6 loopback variants (::1, ::ffff:169.254.169.254) or decimal and octal representations of IPs (2852039166 or 0xa9fea9fe) bypass filters that compare literals.
Additional URL encoding, trailing dot domains, mixed case, or the use of localhost versus 127.0.0.1 versus [::1] are variations that break fragile blocklists.
Defense in depth
SSRF defense requires several layers, assuming each one can fail individually.
The first is to always operate with explicit allowlists of destinations, not blocklists. A blocklist trying to enumerate private IPs, loopbacks, link-local, and cloud ranges is doomed to fail given the enormous number of variants. An allowlist that specifies exactly the legitimate external domains for the business is manageable and robust.
The second is to control server side DNS resolution. The application should resolve the host, validate that the resulting IP does not belong to private ranges, and connect to that resolved IP, preventing a later DNS change from triggering rebinding.
The third is network policy at the infrastructure level. The segment where applications run should not be able to talk to 169.254.169.254 except for legitimate system processes. Modern cloud networks allow denying metadata egress from application workloads.
The fourth is to require IMDSv2 on AWS with HttpTokens=required and HttpPutResponseHopLimit=1. The hop limit prevents nested containers from accessing host metadata. The required header and PUT method break SSRFs based on naive GET.
The fifth is per workload egress firewalling. Each application should have an outbound policy that limits which destinations it can reach, just as inbound is restricted. Service mesh platforms and Kubernetes network policies make this granularity practical.
The sixth is robust URL validation through specialized libraries, not ad hoc regular expressions. Parse the host correctly, discard non allowed schemes, normalize and compare against the allowlist.
The seventh, and perhaps the most strategic, is to adopt workload identity (IRSA on EKS, Workload Identity on GKE, Managed Identity on AKS) which removes the dependency on IMDS as a credential source. Where viable, the metadata endpoint stops being the source of secrets.
SSRF in modern APIs
SaaS APIs and platforms offering flexible integrations concentrate structural SSRF risk. Webhook customizers allow customers to declare destination URLs for events, which is legitimate and sellable functionality, but it opens the door to pointing at the internal metadata service if the platform does not segment correctly.
URL preview services, common in chat and collaboration applications, fetch links to display thumbnails and descriptions. Without an allowlist, they are textbook SSRFs.
PDF generators that accept HTML or URL as input render in a headless browser that downloads assets. If the browser can request arbitrary resources, metadata is reachable.
Screenshot services share the same profile. A legitimate UI testing integration can become IMDS exfiltration if the instance where it runs holds sensitive credentials.
In all cases, the correct solution is to run the fetcher component in a network without metadata access, with controlled egress, or to use specialized providers that isolate that workload.
How to test SSRF in an audit
In pentest, the first step is to enumerate inputs that accept URLs: avatar fields, feed import, webhook configurations, third party integrations, redirect parameters, report generation with remote assets.
The second phase uses out of band testing with a controlled external collaborator. Tools such as Burp Collaborator generate a unique domain, and any interaction against it, DNS or HTTP, is recorded. Injecting that domain into every input detects blind SSRF without needing a visible response.
The third phase introduces cloud specific payloads depending on the target provider. If the application runs on AWS, variants of 169.254.169.254 with all encodings, IMDSv2 token negotiation, and known IMDS paths are tested. If GCP or Azure, their respective endpoints with required headers are tested.
The fourth phase tests bypasses when validation is present: redirects, DNS rebinding, IPv6, alternative encoding.
OAST tooling is complemented by custom servers capable of serving responses with redirects or returning changing IPs for rebinding. In serious audits, internal collections of proven payloads are maintained.
Fit with OWASP Top 10 and cloud security
SSRF appeared for the first time as its own entry in OWASP Top 10 2021 as A10, explicit recognition of its growth as a critical vector. Until then, it was subsumed into other categories.
In cloud security frameworks, the CIS Benchmarks recommendations for AWS, Azure, and GCP include controls directly related to SSRF and metadata: require IMDSv2, restrict hop limit, deny application access to the metadata endpoint from the network, use workload identity.
Modern CSPM services identify configurations that accept IMDSv1 and flag them as critical findings. Integration with manual pentest is complementary: CSPM detects the insecure configuration, pentest verifies whether an application actually exploits it.
Frequently asked questions
Is SSRF the same as CSRF?
No. CSRF runs in the victim's browser and abuses authenticated sessions in sites where the victim is already signed in. SSRF runs in the application server and abuses the server's ability to make network requests. Different mitigations, different impact.
Does IMDSv2 eliminate SSRF risk on AWS?
It reduces significantly, it does not eliminate. IMDSv2 cuts off SSRFs based on simple GET without controllable headers, which are the majority. But if the application executes full HTTP requests with arbitrary headers and methods, IMDSv2 is still reachable. Combining it with restricted egress and workload identity is the correct posture.
Allowlist or blocklist?
Allowlist always. Blocklists enumerating private ranges lose against creativity in encoding, DNS rebinding, and new representations. Allowlist over the few legitimate external domains is maintainable and robust.
What is DNS rebinding?
An attacker controls a domain whose DNS responds first with a public IP (which passes validation) and, seconds later, with an internal IP such as 169.254.169.254. If the application validates at one moment and connects at another, the destination has changed between the two.
Are microservices architectures more exposed to SSRF?
They tend to be. More components making internal requests, more configurable URLs between services, more webhook surface, and more egress complexity. Defense requires per service network policies and service mesh with fine grained control.
How to detect SSRF in logs?
By looking for outbound requests from applications to unexpected destinations, especially private IPs, loopbacks, or metadata ranges. Egress firewall or service mesh logs are the most reliable source. Alerts must fire on any attempt by a legitimate application to talk to 169.254.169.254 if it is not authorized.
Related resources
- What is CSRF: cross-site request forgery
- Cloud pentesting on AWS, Azure and GCP
- Cloud misconfigurations on AWS and Azure
- API penetration testing REST and GraphQL
- What is Burp Suite in web pentesting
- Web application penetration testing
- What is CORS and web security
Cloud native SSRF audit with Secra
At Secra we run security audits that treat SSRF as a first order vector in cloud native environments. The service combines application pentesting, validation of SSRF plus IMDS attack chains specific to AWS, Azure, and GCP, review of per workload egress policies, and verification of the IMDSv2 and workload identity posture. We deliver actionable findings prioritized by real impact on the exposed credentials and cloud resources, together with operational hardening recommendations. If you need to validate the SSRF exposure of your cloud applications or close the exploitation chain against metadata services before an attacker discovers it, contact our team through this page.
About the author
Secra Solutions team
Ethical hackers with OSCP, OSEP, OSWE, CRTO, CRTL and CARTE certifications, 7+ years of experience in offensive cybersecurity, and authors of CVE-2025-40652 and CVE-2023-3512.