Server-Side Request Forgery

Server-side request forgery lets an attacker make a server issue requests to arbitrary URLs, exposing internal services, cloud metadata, and local files. SSRF reports in this corpus consistently exploit features that fetch a user-controlled URL: webhook configuration, link previews, image/avatar fetchers, video/PDF processors, document import, OAuth redirect_uri, and headless screenshot tools. Two impact tiers dominate:

• blind SSRF - collaborator hits prove server-side fetch but no response is reflected, useful for internal port scanning and pivoting
• read SSRF - response is reflected to the user, enabling cloud-metadata theft (AWS EC2 169.254.169.254, GCP, DigitalOcean, Azure IMDS) and local file inclusion via file:// or alternate URI schemes. The payload library has matured around bypasses for naive allowlists: DNS rebinding, redirect chains, decimal IPs, IPv6 mapped, trailing-dot domain confusion, gopher://, dict://, file://, long URL-scheme parser bugs, SVG/PDF rendering side-channels, and OOB DNS detection.

• Webhook / integration configuration endpoints (helium.com, omise, slack-style)
• Link / URL preview features (chat widgets, share-cards, og:image fetch - stripo, line manager)
• Image / avatar / favicon fetch by URL (acronis admin-ajax, generic profile-pic upload)
• Document import and conversion (Lark Docs, GitLab FogBugz import, evernote /ro/<base64>)
• Video upload pipelines processing m3u8 with FFmpeg (TikTok)
• PDF / HTML to PDF rendering (wkhtmltopdf, Headless Chrome screenshot - shopify themes)
• OAuth / OIDC authorize endpoints accepting request_uri or redirect_uri pointing externally (Keycloak)
• WordPress xmlrpc.php pingback methods
• API endpoints that accept a URL parameter named url, link, callback, image, preview, fetch, import, redirect_uri, source, target, address, masterUrl
• Microsoft Exchange CVE-2021-26855 (ProxyLogon) reachable services

• Submit collaborator URL in webhook/link-preview/image-fetch/avatar/import field
• Fetch http://169.254.169.254/latest/meta-data/ (AWS EC2 IMDSv1) and exfiltrate IAM
• Use DNS rebinding (1u.ms, rebind.network) to swap allowlisted IP -> 127.0.0.1 between checks and fetch
• Submit redirect URL on attacker domain that 301/302/307s to internal target
• Use file:// to read /etc/passwd, /proc/self/environ, AWS credentials files
• Use gopher:// to forge SMTP, Redis, MySQL packets through HTTP fetcher
• Embed SSRF payload inside m3u8 / HLS playlist passed to FFmpeg for video upload
• Embed external entity in XML uploaded to PDF/Office processor
• Long URL-scheme name in libcurl to bypass scheme allowlist
• Trailing-dot host (target.internal.) to bypass naive deny-list

• http://169.254.169.254/latest/meta-data/iam/security-credentials/
• http://metadata.google.internal/computeMetadata/v1/?recursive=true&alt=json
• http://100.100.100.200/latest/meta-data/ (Alibaba)
• http://[::ffff:a9fe:a9fe] (IPv6-mapped 169.254.169.254)
• http://2852039166/ (decimal IP for 169.254.169.254)
• http://0177.0.0.1/ (octal 127.0.0.1)
• http://0/ (shorthand 0.0.0.0)
• http://localhost.attacker.com/ (DNS rebind initial answer)
• file:///etc/passwd
• file:///proc/self/environ

Layered probing using OOB callbacks.

From recon URLs, classify parameters whose name matches /url|link|callback|image|preview|webhook|fetch|import|redirect_uri|source|target|address|host|path|file|src|dest|proxy/i; from JSON/POST bodies, classify any value that is itself a URL.

Inject a per-target unique collaborator URL (https://<token>.<oast-domain>/) and watch DNS+HTTP for that token.

On confirmed SSRF, attempt the IMDS endpoints for AWS, GCP, Azure, Alibaba, DigitalOcean and reflect any response into the finding.

If vanilla payload fails, retry with the bypass set (decimal IP, octal IP, IPv6-mapped, trailing-dot, userinfo @, alternate-port confusion, shorthand 0, localhost.<attacker>, long-scheme curl).

If hostnames are validated but IPs are not, point at a rebinding service (e.g. 1u.ms / rebind.network) and watch IMDS exfiltration.

Host a 302 redirect to an internal target on the attacker domain and detect via collaborator.

Retry with file://, gopher://, dict://, ftp://, jar:// to detect non-HTTP fetcher behavior.

If /xmlrpc.php is reachable, send pingback.ping and detect OOB.

If Microsoft Exchange or Apache HTTPD vulnerable versions are detected (already covered by nuclei), emit a high-confidence pre-auth SSRF finding. Confidence is graded by independent OOB hits and protocol class.

Tip: Testing tools that run these checks in parallel across every discovered endpoint can cut the time required substantially compared to fully manual testing, as long as they confirm findings with more than one signal to keep the false-positive rate down.

• Many sites legitimately fetch external URLs, such as RSS readers, link unfurlers, and screenshot services.
• The mere fact of an outbound HTTP request is not a finding by itself.
• What matters is distinguishing between an intentional outbound fetch that respects a documented allowlist and a fetch that escapes that allowlist into private address ranges, link-local addresses, or the cloud metadata API.
• A layered confidence score helps here: a collaborator hit alone is informational, a collaborator hit plus metadata-service reflection is high confidence, a collaborator hit plus private IP reflection is medium, and a CVE-marker match against a known-vulnerable component is critical.
• It's also worth avoiding testing the same parameter twice in rapid succession, to prevent rate-limit blowback.

Manual Testing Methodology

Here is a systematic approach to identifying Server-Side Request Forgery vulnerabilities in a target application.

Before testing, map all input vectors that could be affected. Identify parameters, headers, cookies, and request bodies that interact with the vulnerable component. A proxy such as Burp Suite or OWASP ZAP, paired with normal browsing of the target, is usually enough to build this list.

Send a legitimate request and record the normal response: status code, content length, response time, and any identifying tokens. This baseline matters because it's what you'll compare later responses against once payloads are involved.

Inject test payloads into each identified input vector one at a time. Start with benign detection payloads before escalating to anything that could actually trigger the vulnerability. For Server-Side Request Forgery specifically, point every URL-accepting parameter at an out-of-band collaborator domain first to catch blind SSRF via DNS or HTTP callback, then escalate to internal targets — http://169.254.169.254/latest/meta-data/, http://localhost:<common-ports>, and internal hostnames — once any outbound reach is confirmed.

Compare the response against your baseline, looking specifically for a callback hit on the collaborator domain (proof of blind SSRF even with no visible response difference), or metadata/internal-service content reflected directly into the application response for the non-blind case.

Once a potential vulnerability is detected, confirm it with at least a few independent test cases to rule out coincidence. Document the exact request and response as proof. For Server-Side Request Forgery, a confirmed finding typically means showing that attacker-controlled input changes the application's behavior in a way that matters for security, not just that a payload was reflected somewhere harmless.

Real-World Impact

Server-side request forgery lets attackers make the vulnerable server send requests on their behalf, reaching internal services, cloud metadata endpoints, and private networks that would otherwise be firewalled off from the public internet. This is especially damaging in cloud environments, where the metadata endpoint can hand over temporary IAM credentials to anyone who can reach it.

In real attacks, SSRF has been used to read cloud credentials from instance metadata services, reach internal admin panels and databases, scan internal networks port by port, and chain into full remote code execution. The Capital One breach in 2019 was fundamentally an SSRF exploitation against AWS metadata.

Cloud-native applications are especially exposed here, since the metadata endpoint is reachable from any process running on the instance, and SSRF gives an outside attacker that same reach from beyond the network perimeter.

Prevention and Secure Coding

Preventing Server-Side Request Forgery takes a defense-in-depth approach — no single control below is sufficient alone, but together they close off both the primary path and the most common bypasses.

Allowlist destinations. Restrict outbound requests from server-side fetchers to an explicit allowlist of hosts and schemes — a denylist of "internal" ranges is reliably bypassable through DNS rebinding, redirects, and alternate IP encodings.

Re-validate after every redirect. If the fetcher follows redirects, re-apply the same destination check on the final resolved URL, not just the one the user supplied — a redirect chain is a standard SSRF bypass for a check that only runs once.

Block link-local and private ranges. At minimum, block requests to 169.254.169.254 (cloud metadata), 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 from any component that fetches user-supplied URLs.

Enforce IMDSv2 (or equivalent). On AWS specifically, IMDSv2 requires a session token obtained via a PUT request that most SSRF vectors can't replicate, which closes off the classic metadata-read pattern even if a fetcher is otherwise vulnerable.

Network-level egress filtering. Firewall rules restricting what internal ranges application servers can reach at all provide defense-in-depth beyond the application-layer allowlist.