In modern applications, servers constantly communicate with other systems — APIs, internal services, cloud metadata endpoints, third-party integrations.

But what happens when attackers trick your server into talking to places it shouldn't?

That's where Server-Side Request Forgery (SSRF) comes in.

What is SSRF?

SSRF occurs when an application fetches a remote resource based on user input, and an attacker manipulates that input to make the server send unintended requests.

Instead of the attacker sending the request directly, they force your server to send it.

Think of it like this:

The attacker whispers a malicious URL, your server obediently visits it.

Simple Example

Imagine a web app that fetches images from a URL:

https://example.com/fetch?url=https://images.site.com/photo.jpg

The server takes the url parameter and fetches it.

Now an attacker changes it to:

https://example.com/fetch?url=http://localhost/admin

If not validated, the server may fetch internal resources like:

And that's where things become dangerous.

Real-World Impact

SSRF is powerful because it can:

  • Access internal systems not exposed publicly
  • Retrieve sensitive cloud metadata (AWS keys, tokens)
  • Bypass firewalls
  • Scan internal networks
  • Lead to Remote Code Execution in some cases

Many high-profile cloud breaches started with SSRF.

Cloud Example (Very Important)

In AWS environments, the metadata service lives at:

http://169.254.169.254/latest/meta-data/

If SSRF is possible, attackers can access:

  • IAM credentials
  • Instance role tokens
  • Configuration data

This can lead to full cloud compromise.

Common SSRF Entry Points

Look for features that:

  • Import files from URLs
  • Fetch images from links
  • Webhook integrations
  • URL previews
  • PDF generators
  • API connectors

If the server fetches a URL based on user input, SSRF might exist.

Types of SSRF

1. Basic SSRF

The server directly returns the fetched response.

Example: Attacker requests internal admin panel and sees the response.

2. Blind SSRF

The attacker doesn't see the response.

Instead, they detect:

  • DNS interactions
  • Outbound requests
  • Timing differences

Blind SSRF is harder to detect but equally dangerous.

How to Prevent SSRF

SSRF is preventable with proper validation and architecture.

Here's how:

1. Whitelist Allowed Domains

Instead of allowing any URL:

❌ Accept user-provided URLs blindly ✅ Only allow specific trusted domains

Example: Allow only:

  • api.partner.com
  • cdn.images.com

Block everything else.

2. Block Internal IP Ranges

Reject requests to:

  • 127.0.0.1
  • 10.0.0.0/8
  • 192.168.0.0/16
  • 169.254.169.254

Your application should never fetch internal addresses from user input.

3. Disable Unnecessary URL Fetching

If URL fetching is not required, remove it completely.

Less functionality = less attack surface.

4. Use Network Segmentation

Even if SSRF happens:

  • The server should not have access to sensitive internal system
  • Cloud metadata should require authentication (e.g., IMDSv2 in AWS)

Limit blast radius.

5. Use Outbound Firewall Rules

Control where the server can send requests.

Don't allow outbound access to internal networks unless required.

Why SSRF Was Added to OWASP Top 10

SSRF became more common due to:

  • Cloud adoption
  • Microservices architecture
  • API integrations
  • Complex backend systems

Modern applications are interconnected.

And every connection is a potential doorway.

Final Thoughts

SSRF is dangerous not because it's flashy, but because it abuses trust between systems.

It turns your server into a proxy for attackers.

The fix isn't complicated — validate input, restrict access, segment networks.

But ignoring it can lead to cloud compromise, data leaks, and infrastructure takeover.

🔐 That concludes the OWASP Top 10 series.

If you found this helpful, feel free to connect and follow for more practical application security breakdowns.