Server-Side Request Forgery (SSRF) might be last on the OWASP Top 10, but it’s far from low risk. By tricking a server into making unintended requests, attackers can bypass firewalls, steal cloud credentials, or pivot deeper into internal systems. Let’s break it down.

–

01 – What is SSRF?

SSRF occurs when an application lets users supply a URL or destination that the server then uses to fetch data – without proper validation. Attackers abuse this to make the server initiate requests to internal or sensitive locations that the attacker couldn’t reach directly.

For example, if an app fetches a user–supplied image from a URL, an attacker might instead submit:

169.254.169.254/latest/meta-data/

That’s the AWS metadata service, used to expose credentials and config to cloud instances. If the server fetches it and returns the data, the attacker now has internal secrets.

Because the server is trusted on internal networks, SSRF can effectively “bounce” attackers past perimeter controls.

–

02 – How is it exploited?

SSRF vulnerabilities have led to some of the most high–profile breaches:

• Capital One (2019) – An SSRF vulnerability in a WAF allowed attackers to query AWS metadata and extract cloud credentials, leading to the theft of 100M+ customer records.
• GitHub/GitLab CVEs – Past bugs allowed attackers to abuse SSRF to scan internal networks or access services like Redis or PostgreSQL behind firewalls.
• Dependency confusion and cloud metadata – SSRF has been used alongside DNS rebinding, redirect chains, or insecure deserialisation to elevate access or gain lateral movement.

In many cases, SSRF is the first step in a broader chain of compromise.

–

03 – How do you prevent SSRF?

Effective SSRF prevention combines application–layer controls with hardened network architecture:

• Validate and restrict URLs – Enforce an allowlist of safe domains. Block requests to internal IPs (e.g. 127.0.0.1, 10.0.0.0/8, 169.254.169.254) and cloud metadata hosts (metadata.google.internal, 169.254.169.254, etc.).
• Limit schemes and redirects – Allow only necessary protocols (http, https). Block file://, gopher://, and prevent unvalidated redirects.
• Route outbound traffic through a proxy – Use an egress proxy or firewall to enforce outbound request policies. This adds a checkpoint even if validation fails.
• Detect DNS rebinding and chained redirects – Resolve the final IP after DNS resolution and follow redirects cautiously to avoid internal targets.
• Segment the network – Apply least privilege networking. Servers shouldn’t have access to internal admin panels or metadata endpoints unless absolutely required.

–

SSRF turns your server into an internal attacker. But with strict input validation, outbound request controls, and hardened network boundaries, you can shut down one of the most dangerous paths to internal compromise.