Server-Side Request Forgery (SSRF) is a vulnerability where an attacker tricks the server into making requests to unintended locations, often internal systems that are not directly accessible from outside.

Made By AI

Everyday Analogy: The Pizza Delivery Example

Imagine you run a pizza shop. Customers call and give their addresses, and you send a delivery person to deliver the pizza. This is normal, right?

But one day, someone calls and says:

“Hi, instead of my home, can you send the pizza to the secret military base? Also, please deliver this document inside.”

You trust the customer and send the delivery person to the military base with the pizza and the document. A week later, someone else calls:

“What was in that document? Can you read it to me?”

And you unknowingly start revealing classified secrets from the military base through your delivery person.

This pizza shop represents your web application.

The delivery person is your server itself.

The military base is your private network, for example 127.0.0.1 or 169.254.169.254.

And the customer is the attacker.

You tell your server:

“Go fetch the data from this address and bring it to me.”

The server, like a loyal courier, goes and sends a request to the specified address. If that address belongs to a sensitive internal service within the system… that’s SSRF.

How SSRF Attacks Work

SSRF (Server-Side Request Forgery) is an attack where the attacker manipulates the server to send HTTP requests on their behalf. Normally, the server sends requests to external resources based on user input like URLs. However, if proper filtering is not applied, attackers can abuse this mechanism to make the server communicate with internal services that should not be accessible.

These attacks typically occur when an application fetches external URLs — for example, features like “generate screenshot of a webpage” or “download file from image URL” often take a URL parameter controlled by the user. An attacker can replace this URL with an internal address (e.g., http://127.0.0.1:8000) to force the server to send requests to its own internal services.

Not only URL parameters but also HTTP headers like Host, X-Forwarded-For, X-Original-URL or file paths can serve as injection points. Especially in proxy-like services, these headers or parameters can open the door to SSRF.

SSRF vulnerabilities are commonly found in scenarios such as:

In these cases, attackers can bypass the target application’s firewall and reach internal systems. The most dangerous part is that these requests are often made by the server itself — meaning the attacker turns the server into a browser that can query the internal network.

A Simple Example

Imagine an application where you input a URL and it returns a screenshot:

GET /screenshot?url=http://example.com

Behind the scenes, the server runs:

requests.get("<http://example.com>")

But if someone changes the URL to:

/screenshot?url=http://169.254.169.254/latest/meta-data/

This IP address returns AWS metadata. If the application returns this content, the attacker can gain access to the EC2 instance’s credentials.

What Can an Attacker Do With Metadata Access?

Once an attacker obtains credentials via the metadata service, the risks multiply exponentially.

1. AWS API Access

Attackers can use tools like awscli or boto3 to access AWS services:

aws s3 ls --access-key ... --secret-key ... --session-token ...

2. Access S3 Buckets

Common scenarios include:

3. Manage EC2 Instances

If the role has EC2 permissions, attackers can:

4. Access Lambda Functions

If Lambda permissions exist:

5. Access Secrets Manager and Parameter Store

IAM roles often grant access to:

Chain: SSRF → Metadata → Credentials → Secrets Manager → Application secrets 😱

6. Cover Their Tracks

With broad permissions, attackers can delete CloudTrail logs, making detection difficult.

Real World Example: Capital One Data Breach (2019)

SSRF vulnerabilities have been responsible for multi-million dollar breaches and are frequently reported in bug bounty platforms. Here are some of the most notable cases:

Search.gov — SSRF via ?url= parameter
https://hackerone.com/reports/514224

Elastic — Blind SSRF for internal port scanning
https://hackerone.com/reports/1300585

GitLab — SSRF mitigation bypass through DNS
https://hackerone.com/reports/632101

Shopify — SSRF in Exchange endpoint led to root access
https://hackerone.com/reports/341876

Nextcloud — Blind SSRF in Mail App
https://hackerone.com/reports/1741525

Conclusion

SSRF vulnerabilities may seem subtle or low-risk at first glance, but as we’ve seen, they can quickly escalate into full-blown system compromises — especially in modern cloud environments. By exploiting SSRF, attackers can bypass network boundaries, access sensitive internal services, steal credentials, and ultimately gain persistent control over critical infrastructure.

For developers and security teams, preventing SSRF means implementing strict input validation, enforcing allowlists, carefully managing internal service exposure, and continuously testing applications for hidden attack vectors. Awareness and proactive defense are the best ways to ensure your systems stay secure in the face of evolving threats.

Remember: the server is your first line of defense — but if it turns into the attacker’s proxy, the damage can be devastating. Stay vigilant, stay secure.

Understanding SSRF (Server-Side Request Forgery) from Basics to Advanced was originally published in System Weakness on Medium, where people are continuing the conversation by highlighting and responding to this story.