Understanding Server-Side Request Forgery (SSRF)
Sweet team
|
October 18, 2026
Applications routinely fetch remote resources for their users. That ordinary capability turns dangerous when an attacker picks the destination and the server supplies the network trust. An SSRF attack exploits that gap. This guide covers the exploit path, its common variants, its impact, and the controls that interrupt it. The focus is HTTP-based web and cloud workloads; SSRF also appears in contexts such as SSO metadata fetching and server-side XML processing, which are outside this scope.
Key takeaways about SSRF attack
- An SSRF attack lets an attacker supply a destination while the application makes the request from its trusted network position, potentially reaching private services, loopback interfaces, or cloud metadata endpoints.
- Server Side Request Forgery techniques vary by response visibility: direct responses can expose content, while timing, errors, DNS callbacks, and side effects can support reconnaissance or exploitation without visible data.
- URL text validation alone is insufficient because DNS resolution, alternate address formats, redirects, protocol handlers, and rebinding can move a request beyond the destination originally checked.
- SSRF attack prevention requires layered controls: feature-specific allowlists, resolution-aware destination checks, constrained egress, metadata-service hardening, and least-privilege workload identities.
- Defenses against SSRF should also observe real outbound behavior and retest URL-consuming features after code or infrastructure changes, including parsers, renderers, callbacks, and integrations.
Run AI on a secured infrastructure.
See Sweet secure your cloud-native applications and AI agents in one platform, in a 30-minute walkthrough.
What is an SSRF attack?
Server-side request forgery happens when an application accepts a destination from an untrusted source and then issues an outbound request to it from its own network position. The weakness is catalogued as CWE-918 and was added to the OWASP Top 10 as category A10 in the 2021 revision. Making outbound requests is the feature; the flaw is that the requester is privileged and the destination is attacker-chosen.
The asset being abused is the server's trusted network location. A workload inside a VPC can usually reach private subnets, internal admin interfaces, service discovery endpoints, and the cloud instance metadata service at the link-local address 169.254.169.254. None of those are reachable from the internet, which is precisely why an attacker wants the application to reach them instead.
This is why the common answer to "what is an SSRF attack," a malicious URL in a form field, understates the problem. The input is the trigger; the trust is the vulnerability.
How SSRF attacks work: from request to exploit
The useful view is a single request traced from submission to response, because that is where a destination the developer never intended becomes one the server willingly contacts.
The trusted server request flow
Consider a document-preview endpoint. A user submits a URL, the application downloads the file server-side, renders a thumbnail, and returns it. The feature exists because the browser cannot reach the source directly or because rendering must happen in a controlled environment. Every design assumption here is reasonable.
The exploit begins when the submitted value is treated as data to fetch rather than a destination to authorize. The application parses the string, resolves the hostname, opens a connection, and returns whatever comes back. At no point does it ask whether the resolved address belongs to an approved destination set. Trust has shifted from an intended endpoint to an attacker-selected one.
The same pattern appears anywhere a service consumes a caller-supplied location: webhook registration, image import, PDF generation, link unfurling, XML and feed parsers, and API integrations that proxy requests between backend services. Wherever a destination is an input, the request path needs the same scrutiny as any other privileged operation.
Targeting internal services and metadata endpoints
Once an attacker controls the destination, the interesting targets are the ones the perimeter was built to hide.
High-value internal destinations
- Cloud metadata service: Returns instance identity and, on unhardened configurations, temporary IAM credentials.
- Internal control-plane endpoints: Orchestrator APIs, service meshes, and admin consoles that trust in-cluster callers.
- Private service ports: Databases, caches, message brokers, and search clusters with network-based authorization.
- Link-local and loopback addresses: Local agents and sidecars that assume any local caller is legitimate.
Whether an attacker can confirm a hit on any of these depends on two things the request path controls: how much of the response comes back, and how the destination was resolved in the first place.
Common types and variations of SSRF attacks
Response visibility and resolution behavior are what separate SSRF variants from one another. The underlying abuse is the same in each case, outbound trust, but the attacker's workflow and the defender's evidence differ.
Basic, blind, and semi-blind SSRF
Blind SSRF is frequently dismissed as low severity because nothing visibly leaks. That assumption fails when the request itself causes a side effect, such as triggering an internal job, writing to a queue, or authenticating against a service that logs the caller as trusted.
SSRF through URL parsers, redirects, and protocols
The variants above describe what an attacker learns. A separate class of techniques decides whether naïve validation even applies. The OWASP SSRF Prevention Cheat Sheet is explicit that string-level checks on user-supplied URLs are unreliable, and the reasons are structural.
A hostname that passes validation can resolve to a private address, because validation inspects text while the connection uses DNS. Alternate address representations in decimal, hexadecimal, octal, and IPv4-mapped IPv6 form, such as ::ffff:169.254.169.254, defeat pattern matching on familiar private ranges.
Redirects move the pivot after the check: the approved host answers with a 3xx response pointing elsewhere, and permissive HTTP clients follow by default. Time-of-check to time-of-use gaps, including DNS rebinding, let the resolved answer change between validation and connection, typically by serving a short-TTL record that flips from a public to a private address. Protocol handling adds another seam, since clients that accept schemes beyond HTTP and HTTPS can be steered toward file://, gopher://, or similar handlers, widening the blast radius well past web content.
Visualizing the threat: an SSRF attack diagram
Every defensive control discussed later interrupts one of these transitions. Which one matters most depends on what the server can reach once stage seven succeeds.
Real-world impact and risks of server-side request forgery
Impact follows access. The severity of a server-side request forgery finding is determined less by the vulnerable parameter than by the reachability of the workload holding it.
Cloud credential theft and metadata service exposure
In cloud environments, the instance metadata service is the highest-value destination because it converts a read primitive into an identity. A successful request can return temporary credentials bound to the workload's IAM role, after which the attacker operates with legitimate API access rather than through the vulnerable application.
What those credentials unlock depends on the role attached to the workload. An over-permissioned task role turns a preview feature into object-storage access, secret retrieval, or cloud account discovery. The 2019 Capital One breach is the most widely documented example of this chain: according to the Department of Justice indictment and Capital One's own disclosure, a misconfigured web application firewall was induced to query the AWS metadata service, and the resulting role credentials were used to read customer data from S3. AWS introduced IMDSv2 shortly afterward because the original request flow made this pivot trivial for any SSRF primitive.
Internal network reconnaissance and data exfiltration
Credentials are not the only prize. Even semi-blind responses let an attacker map which internal hosts exist, which ports answer, and which services return recognizable errors, reconnaissance that would otherwise require a foothold inside the network.
From there the path depends on what those services expect. Internal APIs that authorize by network origin treat the application as a legitimate caller. Admin interfaces that were never exposed externally accept requests without challenge. Data leaves through the application's own response or through an outbound connection the attacker specifies. In each case the attacker never breached the perimeter; the application carried the request across it.
Prevention therefore has to answer a different question than "is this URL well-formed?" The question is what destinations this workload can actually reach.
SSRF attack prevention best practices
Effective SSRF prevention works at two levels: making unintended destinations unrequestable in application logic, and making them unreachable at the network layer. Neither is sufficient alone, so the practices below are layered.
Use allowlists and strict URL validation
Denylists fail against every encoding and resolution trick described earlier, because they require enumerating what is forbidden. Allowlists invert that burden: the application names the hosts, schemes, and ports it legitimately needs, and rejects everything else.
Validation rules worth enforcing
- Approved destination set: Match against an explicit list of hosts or domains, defined per feature rather than globally.
- Scheme restriction: Permit HTTP and HTTPS only; reject file, gopher, dict, and other handlers outright.
- Resolution-aware checks: Validate the resolved IP address, not just the hostname string, and reject loopback (127.0.0.0/8, ::1), link-local (169.254.0.0/16, fe80::/10), and RFC 1918 private ranges.
- Redirect handling: Disable automatic redirect following, or revalidate the destination at every hop.
- Response discipline: Return rendered output rather than raw upstream responses, and avoid echoing error detail.
Validation written this way removes the easy paths. Resolution-aware checks still leave a narrow rebinding window unless the validated address is the one actually connected to, and the approach depends on parsers, HTTP clients, and third-party libraries behaving as documented. The network layer has to assume validation will eventually be bypassed.
Restrict outbound network access
Default-allow egress is what makes an SSRF primitive valuable. If a document-preview workload can only reach two approved domains and nothing else, the same vulnerable code yields far less.
Scope egress policy per workload rather than per VPC. Route external fetches through a forward proxy that enforces the approved destination set independently of application code, and deny traffic to private ranges and link-local addresses from any workload that has no business reaching them. This control sits outside the vulnerable service and survives a bad deployment. Its limit is operational: egress allowlists need maintenance as integrations change, and overly broad exceptions quietly restore the original exposure.
Protect cloud metadata services
Egress policy rarely blocks the metadata endpoint, since it is local to the instance. Hardening it directly is a separate requirement.
- Enforce IMDSv2 on AWS. It requires a PUT request to obtain a session token before any metadata is returned, a step a simple GET-based SSRF cannot perform.
- Set the metadata response hop limit so containerized workloads cannot reach the endpoint unintentionally.
- Rely on required headers in Azure and Google Cloud. Azure's instance metadata service requires Metadata: true and Google Cloud requires Metadata-Flavor: Google, both of which resist SSRF primitives that cannot set custom headers.
- Block metadata access entirely from workloads that never use it.
- Apply least privilege to the attached role. Metadata hardening reduces credential theft; a tightly scoped role determines what stolen credentials are worth.
Together these controls narrow exposure, but they cannot guarantee that every parser, integration, and production configuration change keeps the trust boundary intact.
Defenses against SSRF: detection and mitigation strategies
Defenses against SSRF at runtime exist for that residual case. They do not replace secure request handling, constrained egress, or metadata hardening. They answer a different question: does the outbound behavior happening in production still match the destination set the architecture approved?
Monitor outbound requests and suspicious destinations
Runtime evidence is what separates an assumed trust boundary from an observed one. The signals that matter are specific to the SSRF request path, not generic anomalies.
Runtime signals that indicate SSRF activity
- Unexpected outbound connection: A workload contacts a destination outside its established behavioral baseline.
- Metadata endpoint access: A service that has never queried instance metadata suddenly does.
- Private-range requests: An internet-facing application opens connections toward internal subnets or loopback addresses.
- Resolution anomalies: A previously stable hostname begins resolving to private addresses, or redirect chains terminate internally.
- Process-to-network mismatch: A rendering or parsing process originates traffic it has never generated before.
Legitimate deployments, service migrations, and new integrations produce the same patterns, so interpreting these signals requires workload context: which service, which identity, which cloud resource. Several runtime security products provide that correlation. Sweet Security is one such runtime detection and response platform, pairing application behavior with cloud identity data so teams can investigate an unexpected outbound connection and contain the affected workload while the underlying flaw is fixed.
Validate fixes with security testing
Containment buys time; verification closes the issue. Test every URL-consuming feature with resolution-level cases rather than string-level ones: hostnames that resolve to private addresses, redirect chains that terminate internally, alternate address representations, and blind cases confirmed only through out-of-band DNS or HTTP callbacks. Include non-obvious consumers such as feed parsers, PDF renderers, and integration callbacks in the same scope.
Retest after infrastructure changes as well as code changes. A new egress rule, a replaced HTTP client, or a relaxed security group can reopen a path that application fixes alone had closed.
The decisive question in an SSRF attack has never been whether a URL looked valid. It is whether a production workload can make a request outside its intended trust boundary. Secure request handling makes unintended destinations unrequestable, egress policy makes them unreachable, metadata hardening makes a successful request less valuable, and runtime monitoring tests whether all three still hold under real conditions.
As applications take on more integrations and more autonomy over what they fetch, that boundary gets harder to assume and more important to observe, a shift explored further in the complete runtime security guide.
SSRF attack FAQs
Why is SSRF dangerous in cloud-based applications?
SSRF is dangerous in cloud environments because a vulnerable workload may reach instance metadata services and obtain temporary credentials or access private services that are not internet-facing. The resulting impact depends on the permissions attached to the workload identity.
Which application features are most likely to introduce an SSRF vulnerability?
Features that fetch caller-supplied destinations are most likely to introduce SSRF, including document or image previews, webhook registration, link unfurling, feed and XML parsers, PDF generation, and backend integrations. Any feature that treats untrusted input as a network destination needs destination authorization.
Can SSRF reach localhost, private IP addresses, or internal admin services?
Yes, SSRF can reach loopback, private, link-local, and internal admin destinations when the vulnerable server has network access to them. This lets attackers use the application's trusted network position to bypass internet-facing perimeter controls.
How can attackers exploit SSRF when the application does not return the target response?
Attackers can exploit blind SSRF through timing differences, error behavior, DNS or HTTP callbacks, and observable side effects such as triggering internal jobs or queue activity. These signals can support reconnaissance or confirm that the server contacted an attacker-controlled or internal destination.
Why are URL denylists and simple hostname checks ineffective against SSRF?
URL denylists and hostname-only checks can be bypassed by alternate IP address formats, DNS resolution to private addresses, redirects, protocol handlers, and DNS rebinding. Effective validation must restrict approved schemes, hosts, and ports while checking the resolved destination at connection time.
What should teams test after fixing an SSRF vulnerability?
Teams should retest every URL-consuming feature with private-resolution hostnames, redirect chains, alternate address formats, and blind out-of-band callback cases. They should also verify that infrastructure changes, HTTP-client updates, and egress-policy changes have not reopened access to unintended destinations.
