Server-Side Request Forgery (SSRF)
The server is tricked into sending requests to a destination the attacker chooses, crossing internal network boundaries.
What is SSRF?
SSRF happens when an attacker can force the server to send requests to a destination of their choosing. Many legitimate features accept a URL from users, for example 'fetch link preview', import-image-from-URL, or webhooks. If the destination isn't validated, the attacker turns a trusted server into a 'proxy' to reach places that should be closed off. Try it in the demo tabs.
The favorite target: cloud metadata
In cloud environments (AWS, GCP, Azure) there's a special address, 169.254.169.254, that returns instance metadata, including temporary IAM credentials. If an SSRF-vulnerable server is forced to fetch that URL, the attacker can steal the credentials and impersonate the server inside the cloud. This is the pattern behind several major breaches.
How to prevent it
Never fetch a user's URL raw. Reject internal addresses (metadata, loopback 127.0.0.1, and private ranges like 10.x, 192.168.x, 172.16-31.x), then apply an allowlist of genuinely trusted hosts. Watch out for evasion tricks like redirects and DNS mapping to internal IPs; validation must be done on the resolved IP, not just the URL string.
Impact
SSRF can unlock access to internal services, admin panels, databases, and cloud credentials, often becoming a stepping stone to pivot deeper into the network. Because the request comes from a trusted server, ordinary firewalls frequently fail to stop it.