Tricking the Server into Fetching for You

Server-Side Request Forgery (SSRF) happens when an application accepts a URL and fetches it on the server. The horror is architectural: the server sits inside the trusted network with privileged access, so a request the attacker never could make — to the internal database, the cloud metadata service, or an admin-only management port — becomes possible through the server as a proxy.

Where SSRF Lives

Every "let the server reach a URL" feature is a candidate: image preview/proxy endpoints (?img=https://...), webhook validators, PDF renderers of arbitrary pages, payment/invoice parsers, CSV import, website screenshot services, and library functions that follow links. Following redirects opens the box further: a curl following a redirect chain to an internal hostname passes the allowlist on hop one and lands on the internal network at hop two. The attacker substitutes the target: instead of https://example.com/photo.jpg, the payload is http://169.254.169.254/latest/meta-data/ (the AWS/cloud metadata endpoint that hands out instance credentials to anything on the box) or http://127.0.0.1:6379/ (a Redis management interface nobody meant to expose). Follow-redirects and DNS rebinding amplify the reach: the check passes ("host is example.com"), then the request lands on 10.0.0.5 anyway.

Why Blacklists Fail

Blocking only 127.0.0.1 but allowing anything else sounds reasonable and fails constantly. Alternate representations slip past string filters: decimal/hex IP notation, IPv6 ::1 and link-local forms, DNS names that resolve to internal ranges, and, classically, the redirect that follows the allowlist decision. The defensive shape is a hostname allowlist (only fetch exactly the domains the feature needs), reject any scheme that is not https, and refuse to follow redirects by default or re-validate every hop. Enforce DNS resolution and the fetched response rather than trusting a browser-local filter, because the request that matters is the one the server actually performs.

The Metadata Beast

The notorious SSRF target is the cloud metadata service. On AWS it answers http://169.254.169.254/latest/meta-data/ with instance role credentials; on GCP (metadata.google.internal) and Azure the same concept exists. An SSRF that reaches it yields the cloud identity token, which the attacker then uses against the wider account — pivoting from "server that reads files" to "credentials to the cloud". If you see URL-fetch controls in a review, ask explicitly: does any endpoint accept a URL, does anything allowlist a fetch, and does anything ever touch 169.254.0.0/16?

The Layered Defense

Fix structurally, not cosmetically. Serve internal resources only by identifier (the app fetches document_id, you resolve it to a stored URL); maintain a strict egress firewall so the app's outbound requests are limited to approved external hosts (the firewalls lesson); enable IMDSv2 on AWS so the metadata service requires an explicit token a remote SSRF crawl cannot authenticate; and log URL-fetch activity with alerting so a "who fetched what" trail exists for the incident-response lesson. SSRF is the vulnerability the OWASP Top 10 names as A10 for a reason — the fix is never a filter, it is an architecture that does not let a server fetch arbitrary attacker-chosen URLs at all.