They come from inside the system itself.

And that is exactly what happens in Server-Side Request Forgery (SSRF).

Instead of attacking a server directly, the attacker tricks the server into making requests on their behalf.

The server becomes the attacker.

What is SSRF?

Server-Side Request Forgery (SSRF) is a web security vulnerability where an attacker can force a web application to send requests to unintended locations.

These locations may include:

  • internal servers
  • private APIs
  • cloud metadata services
  • external attacker-controlled systems

Because the request is coming from the server itself, it often bypasses normal security restrictions.

This makes SSRF a very powerful vulnerability.

Why SSRF Is Dangerous

A successful SSRF attack can allow an attacker to:

  • access internal systems
  • retrieve sensitive data
  • bypass authentication
  • interact with backend services
  • sometimes execute commands on internal systems

In some cases, SSRF can even lead to Remote Code Execution (RCE).

Another danger is that the server might attack third-party systems, making it look like the attack originated from the organization.

A Simple SSRF Example

Imagine a shopping website that allows users to check whether a product is available in a store.

Behind the scenes, the website queries a backend API.

When a user checks the stock of a product, the browser sends a request like this:

POST /product/stock
Content-Type: application/x-www-form-urlencoded

stockApi=http://stock.weliketoshop.net:8080/product/stock/check?productId=6&storeId=1

The server reads the stockApi parameter and sends a request to that URL.

Then it returns the result to the user.

Everything works normally.

But what if an attacker changes the URL?

Turning This Into an SSRF Attack

Instead of sending the normal API URL, the attacker modifies the request:

stockApi=http://localhost/admin

Now something interesting happens.

The application server sends a request to:

http://localhost/admin

This means the server is making a request to itself.

Normally the /admin panel is restricted.

But since the request is coming from the local machine, the application may trust it.

As a result, the attacker might gain access to administrative functionality.

Why Servers Trust Local Requests

Many systems treat local requests differently.

Requests coming from localhost or 127.0.0.1 are often considered trusted.

This happens for several reasons:

Sometimes authentication checks are handled by a separate component that sits in front of the application. When the request originates from the server itself, that check may be bypassed.

Some systems allow administrative access from the local machine for disaster recovery purposes. The assumption is that only trusted administrators can access the server locally.

In other cases, the admin interface might run on a different port that external users cannot reach.

These trust relationships are exactly what SSRF exploits.

SSRF Attacks Against Internal Systems

One of the most common SSRF targets is the loopback interface.

Examples include:

http://127.0.0.1
http://localhost

Attackers use these addresses to access services that are normally hidden from the internet.

They may also target internal network ranges, such as:

http://192.168.x.x
http://10.x.x.x
http://172.16.x.

These addresses belong to private networks inside the organization.

If the server can access them, SSRF can expose internal infrastructure.

Circumventing Common SSRF Defenses

Developers often try to block SSRF attacks by filtering certain inputs.

However, these defenses are often weak and can be bypassed.

Bypassing Blacklist Filters

Some applications block inputs like:

127.0.0.1
localhost
/admin

Attackers can bypass this using alternative representations.

For example:

http://2130706433
http://017700000001
http://127.1

All of these represent 127.0.0.1.

Attackers may also use:

  • URL encoding
  • case variations
  • domain names pointing to localhost

Another trick is to send a URL that redirects to the target.

The application validates the first URL but follows the redirect to the malicious one.

Bypassing Whitelist Filters

Some applications only allow requests to specific domains.

But URL parsing can be tricky.

Attackers exploit this using techniques like:

Embedding credentials:

https://allowed-site.com@evil-site.com

Using fragments:

https://evil-site.com#allowed-site.com

Using DNS hierarchy:

https://allowed-site.evil-site.com

These tricks confuse poorly implemented filters.

Using Open Redirects to Bypass SSRF Filters

Sometimes SSRF protection relies on checking whether the URL belongs to an allowed domain.

But if that domain contains an open redirect, the attacker can abuse it.

Example vulnerable endpoint:

/product/nextProduct?currentProductId=6&path=http://evil-site.com

This endpoint redirects users to whatever URL is inside the path parameter.

An attacker can combine this with SSRF:

stockApi=http://trusted-site.com/product/nextProduct?currentProductId=6&path=http://192.168.0.68/admin

The application thinks the request is going to a trusted domain.

But the redirect sends it to an internal system.

This bypasses the filter completely.

Blind SSRF

Sometimes SSRF exists but the application does not return the response from the backend request.

This is called Blind SSRF.

In this case, the attacker cannot see the result directly.

But the server still makes the request.

To detect this, attackers use Out-of-Band techniques.

Detecting Blind SSRF with Burp Collaborator

A common method is using Burp Collaborator.

Burp generates a unique domain like:

abc123.burpcollaborator.net

The attacker sends this domain as a payload.

Example:

stockApi=http://abc123.burpcollaborator.net

If the server makes a request to that domain, Burp Collaborator logs the interaction.

This confirms the application is vulnerable to SSRF.

Exploiting Blind SSRF

Even without seeing responses, blind SSRF can still be dangerous.

Attackers may use it to:

  • scan internal networks
  • probe internal services
  • trigger vulnerabilities on internal servers

If those payloads trigger external callbacks, the attacker knows something inside the network responded.

In some cases, attackers may even achieve remote code execution on internal systems.