OWASP Top 10 – A10: Server-Side Request Forgery (SSRF)

The final item in the OWASP Top 10 is A10: Server-Side Request Forgery (SSRF) — and it’s one of the most interesting (and dangerous) ones I’ve researched.

At first, it sounds simple: “The server makes a request to a URL.”
But if SSRF is possible, an attacker can make the server send requests on their behalf, potentially reaching internal IP addresses, cloud metadata endpoints, or other protected services.

Below are my notes and what I learned while diving into this vulnerability 👇

What Is Server-Side Request Forgery (SSRF)?

SSRF occurs when an attacker tricks the server into making a request to an unintended location, often inside the system itself.

If the application:

Accepts a user-supplied URL,
And sends a request to that URL from the backend (e.g., image fetch, webhook, preview),

Then the attacker can manipulate the input and make the server:

Request internal IPs (http://127.0.0.1, http://10.x.x.x),
Access cloud instance metadata endpoints (e.g., http://169.254.169.254),
Interact with internal-only services that are not exposed to the internet.

Why Is It Dangerous?

It gives attackers access to internal-only services.
APIs, webhooks, image preview tools — all can be abused for SSRF.
In cloud environments, attackers can potentially steal IAM credentials from metadata endpoints.
SSRF is often used for internal scanning, port discovery, or even escalating to remote code execution (RCE).

Even a fully firewalled system is vulnerable if it makes outbound requests using user input.

Real-World Scenarios

1. Internal Network Scanning

An app has a “link preview” feature that fetches a URL’s metadata. An attacker submits http://localhost:8080/admin, and the server requests its own internal admin panel — revealing restricted data.

2. Stealing Cloud Metadata Tokens

In a cloud environment, the app fetches user-supplied URLs. The attacker submits http://169.254.169.254/latest/meta-data/ and obtains cloud access tokens.

3. Abusing Webhooks

A webhook integration lets users specify any URL. The server blindly posts data to it, letting the attacker interact with services behind the firewall.

When Are You at Risk?

If the application makes requests to user-supplied URLs (e.g., image fetch, proxy, preview, webhook).
If there is no validation or sanitization of those URLs.
If access to internal IPs or metadata endpoints isn’t explicitly blocked.
If the server follows DNS redirects or trusts all hostnames.
If SSRF protections are handled only on the frontend.

How to Prevent SSRF

1. Don’t Trust User-Supplied URLs

Avoid allowing arbitrary URL fetching.
If absolutely necessary, validate strictly and whitelist only trusted domains.

2. Use a URL Whitelist

Define and restrict what external domains your app can connect to.
Block everything else by default.

3. Block Access to Internal IPs

Filter out IP ranges like 127.0.0.1, 169.254.x.x, 10.x.x.x, etc.
Also verify DNS resolutions to ensure they don’t point to internal IPs.

4. Use Proxies and Network Segmentation

Route outbound traffic through a secured proxy that can enforce access policies.
Restrict what the app server can connect to internally.

5. Protect Cloud Metadata Services

Restrict access to instance metadata endpoints (in AWS, GCP, Azure).
Don’t assign unnecessary IAM roles to instances.

Best Practices

Practice	Why It Matters
Whitelist user-supplied URLs	Prevents access to unknown or malicious domains
Block requests to internal IP ranges	Stops access to private services and metadata
Verify DNS resolutions	Prevents DNS rebinding or spoofing attacks
Isolate metadata services in the network	Prevents credential theft in cloud environments
Add SSRF protection rules to WAF or IDS	Filters common SSRF payload patterns

How to Test for SSRF

Fuzz URL parameters with internal IPs like 127.0.0.1, localhost, or metadata endpoints.
Use DNS logging tools to detect if the server resolves or requests attacker-controlled domains.
Time-based testing — requests to slow-responding IPs can reveal access via timing.
Use tools like Burp Suite or SSRFmap to automate and explore vulnerable endpoints.

Who’s Responsible?

Developers:

Sanitize and validate all URL inputs.
Check if resolved IPs fall into internal/private ranges.

DevOps & Cloud Engineers:

Restrict metadata endpoints at the network level.
Limit the app server’s outbound connectivity.

Security Teams:

Add SSRF-specific signatures to IDS/WAF.
Use DNS monitoring to detect SSRF attempts.

This topic helped me realize:

If your server can make requests on your behalf — attackers might do the same.

Even services not exposed to the internet can be reached from inside the system, using the system itself as a proxy. This makes SSRF one of the most stealthy and dangerous vulnerabilities out there.

My biggest takeaway from this topic:

Just because something isn’t accessible from the outside, doesn’t mean it’s safe from within.