OWASP API #7 - Server Side Request Forgery (SSRF): When an API Becomes the Attacker’s Proxy

The server retrieves the image from the internet and stores it for the user.

Now imagine an attacker replaces the image URL with an internal server address like http://127.0.0.1 or a cloud metadata endpoint such as [http://169.254.169.254/latest/meta-data/](http://169.254.169.254/latest/meta-data/.).

Instead of fetching an image, the server unknowingly accesses internal resources that should never be exposed.

This is known as Server-Side Request Forgery (SSRF).

What is Server-Side Request Forgery (SSRF)?

SSRF is a vulnerability where an API accepts a user-supplied URL and makes a request on behalf of the user without properly validating the destination.

Since the request originates from the server, attackers may gain access to resources that are normally unreachable from the public internet.

Common SSRF targets include:

• Internal web applications
• Admin dashboards
• Localhost services
• Cloud metadata endpoints
• Internal APIs
• External services used for callbacks or webhooks

Real-World Example: Capital One Data Breach (2019)

One of the most well-known SSRF incidents occurred during the Capital One breach.

Attackers exploited an SSRF vulnerability to access the AWS EC2 Metadata Service, obtaining temporary IAM credentials. Those credentials were then used to access sensitive customer data stored in Amazon S3.

The vulnerability wasn't in AWS itself - it was an application that trusted user-controlled URLs without proper validation.

How Attackers Exploit It

Attackers search for API parameters that accept URLs or external resources.

Typical attack flow:

• Identify URL-based parameters (image, url, webhook, callback, file).
• Capture requests using Burp Suite or Postman.
• Replace legitimate URLs with internal IP addresses.
• Test localhost, private IP ranges, and cloud metadata endpoints.
• Analyze responses for sensitive information.
• Enumerate internal services and continue exploitation if possible.

How Pentesters Should Test

• Identify parameters that accept URLs.
• Test requests to localhost (127.0.0.1) and private IP ranges.
• Attempt access to cloud metadata services (169.254.169.254).
• Use Burp Collaborator or Interactsh to detect blind SSRF.
• Check whether redirects bypass URL validation.
• Verify if DNS rebinding or URL encoding bypasses input filters.
• Observe response content, status codes, and response timing.

Prevention & Best Practices

• Validate and sanitize all user-supplied URLs.
• Allow requests only to trusted domains using an allowlist.
• Block requests to internal and private IP ranges.
• Disable unnecessary outbound network access.
• Restrict access to cloud metadata services.
• Monitor and log outbound requests for suspicious behavior.
• Apply network segmentation and least-privilege principles.

SSRF reminds us that not every attack targets the application directly. Sometimes, attackers simply convince the server to attack itself — or other internal systems — on their behalf.

This is Part 7 of my OWASP API Security Top 10 learning series.

In the next blog, we'll explore OWASP API #8 — Security Misconfiguration and see how default settings, unnecessary services, and poor configurations can expose APIs to attackers.

Until then, feel free to connect with me on LinkedIn:

www.linkedin.com/in/narmadha-natarajan07

Thank you for reading!