Server-Side Request Forgery (SSRF) is a vulnerability where an attacker tricks a web server into making network requests that the attacker should not be able to make directly, often to internal or sensitive services. In normal use, an application might fetch URLs on behalf of users, for example to generate link previews, download images, or call internal APIs. With SSRF, the attacker controls that URL parameter and points it to targets like localhost, internal IP ranges, or cloud metadata endpoints that are normally shielded from the outside world.
Server-Side Request Forgery (SSRF) can escalate from “just fetching a URL” to full environment compromise, because the vulnerable server becomes a powerful proxy into networks and services an attacker could never reach directly.
When SSRF is exploited, the attacker can reach internal services that are normally firewalled, such as internal APIs, databases with HTTP interfaces, admin panels, or cloud metadata endpoints. This often lets them read configuration, credentials, tokens, or other sensitive data that then fuels further attacks or persistence.
By targeting internal endpoints or files, SSRF can leak secrets like API keys, database passwords, and cloud IAM metadata, which can then be used to access data stores or customer information. In cloud breaches, attackers have used SSRF to grab IAM credentials from metadata services and then list, read, and exfiltrate large volumes of sensitive records from storage buckets.
Because the server sits inside the network, attackers can use SSRF to perform internal port scanning and service discovery, learning which hosts and ports are alive and what tech stack is running. That knowledge lets them chain additional exploits, moving laterally from the initial web app into other internal systems that were never exposed to the internet.
In severe cases, SSRF is a stepping stone to remote code execution, for example by hitting internal services that accept URLs, templates, or deserialization payloads. If those services execute attacker-controlled input, SSRF can ultimately give shell access or high-privilege code execution on internal hosts, turning a “simple” bug into total environment compromise.
Here are the most common ways attackers exploit SSRF:
AWS: http://169.254.169.254/latest/meta-data/
GCP: http://169.254.169.254/computeMetadata/v1/
Azure: http://169.254.169.254/metadata/instance
Used to steal IAM tokens → full cloud account takeover.
Attackers probe internal IP ranges:
http://127.0.0.1:
http://10.x.x.x:
http://192.168.x.x:
To identify services such as Redis, Memcached, Elasticsearch, Jenkins, etc.
Examples:
Using file://, gopher://, dict:// to interact with internal services.
Bypassing filters through:
IPv6 localhost: http://[::1]/
Decimal/hex IP encoding: http://2130706433/
Redirect chains to internal IP addresses.
Internal dashboards often lack authentication because they are “internal only,” making SSRF a direct path to:
Admin APIs
Debug interfaces
Monitoring dashboards
Build servers (e.g., Jenkins)
Using SSRF to reach:
Deserialization endpoints
Template engines
Image processing services
PDF or document renderers
This can escalate SSRF → RCE.
Even when no response is shown, attackers use:
DNS exfiltration
Out-of-band services (Burp Collaborator, Interactsh)
Delays (timing-based detection)
To confirm internal access and extract data covertly.
Bypassing SSRF defenses usually means abusing how the application validates URLs, how libraries parse them, or how DNS and redirects behave, so that a payload looks harmless to filters but still reaches internal targets.
When applications block obvious strings like 127.0.0.1, localhost, or admin, attackers try alternative encodings and representations that still resolve to the same target. Techniques include using decimal, octal, or hexadecimal IP formats, IPv6 forms, adding extra dots, URL-encoding characters, or changing case to sneak blocked substrings past naive string checks.
If a whitelist only checks for an allowed domain at the beginning or as a substring, an attacker can exploit URL parser quirks, for example using https://allowed.com.evil.com or credentials-style prefixes to confuse custom validation while the real request goes to an attacker-controlled host. Open redirect bugs on whitelisted domains are also abused: the URL first passes validation, then the server automatically follows the redirect to an internal or malicious endpoint, effectively bypassing the allowlist.
Some defenses resolve the hostname once to ensure it is “external” or not in a private range, but DNS rebinding can change the IP between the initial check and the actual request. By serving a domain that first returns a public IP and then quickly rebinds to 127.0.0.1 or another internal address, attackers can make the SSRF request hit private services despite IP-based protections.
Out-of-Band SSRF (often called blind SSRF with OOB interaction) is a form of SSRF where the attacker never sees the server’s HTTP response directly, but still proves and exploits the bug using callbacks to an external system they control.
In a normal SSRF, the attacker sees the response in the browser, so they can read internal pages or metadata immediately. In Out-of-Band SSRF, the application makes the backend request, but the response is hidden; the only evidence is that the server performed some network activity in the background. To confirm the vulnerability, the attacker supplies a URL pointing to a domain they control and watches for DNS lookups or HTTP hits on that domain using an external interaction service (for example, a Burp Collaborator‑style endpoint).
Non‑obvious SSRF targets are internal or cloud endpoints that are not exposed to the internet but become reachable when a vulnerable server makes requests on an attacker’s behalf.
In cloud environments, metadata services are prime hidden targets because they sit on link‑local addresses like 169.254.169.254 or provider hostnames (for example, AWS IMDS, Azure, GCP metadata). These endpoints often return instance configuration, IAM credentials, tokens, and other secrets that let an attacker pivot into S3 buckets, VMs, or other managed services once accessed through SSRF.
Inside a company network, SSRF can quietly hit internal REST or gRPC APIs, orchestration panels, Kubernetes control services, config servers, or monitoring dashboards that trust traffic from the app server. Other less obvious targets include HTTP‑enabled databases (Elasticsearch, CouchDB), message queues, and identity or SSO backends, where SSRF can trigger privileged actions or data access that were never meant to be exposed externally.
To identify these targets during testing, attackers and testers use SSRF to probe internal IP ranges, watch for timing differences, and look for recognizable banners or error messages that indicate specific technologies. They also rely on common metadata IPs/hostnames for each cloud provider, standard internal service ports, and automated tools or wordlists (for example, from SSRF cheat sheets and payload repositories) to map out reachable but non‑public services behind the vulnerable application.