Published on: August 14, 2026
Server-Side Request Forgery (SSRF) is a vulnerability that occurs when an application allows an attacker to influence where a server-side component sends a network request.
At first glance, this can look harmless. An application may simply be fetching an image, checking whether a website is online, importing data from a URL, generating a preview, processing a webhook, or retrieving content from another service.
The problem is that the request originates from the server, not from the attacker's machine.
That difference matters.
A server may have access to internal systems, private network addresses, administrative interfaces, cloud metadata services, databases, monitoring systems, and other resources that are completely inaccessible from the public internet.
If an attacker can manipulate the destination of a server-side request, the server can unintentionally become a proxy into those otherwise protected environments.
Server-Side Request Forgery is a vulnerability in which an attacker can influence a server-side application or component to make a network request to a destination that the attacker should not be able to access directly.
A simplified model looks like this:
Attacker
|
| Malicious URL
v
Vulnerable Application
|
| Server-side request
v
Internal / Restricted ResourceThe attacker does not necessarily connect directly to the internal resource.
Instead, they convince a trusted server to make the connection on their behalf.
For example, suppose an application provides a feature that checks whether a website is available:
GET /check-status?url=https://example.comThe backend might internally perform something similar to:
GET https://example.comIf the application does not properly restrict the destination, an attacker may attempt to supply a private or local address instead:
GET /check-status?url=http://127.0.0.1/adminThe vulnerable server may then request:
http://127.0.0.1/adminFrom the server's perspective, 127.0.0.1 refers to the server itself.
This can expose administrative endpoints or other services that were never intended to be accessible through the public application.
The important part of SSRF is not simply that the server makes a request.
Servers routinely make outbound requests.
The security problem is where the server can be persuaded to connect and what the attacker can do with the resulting request.
A production server might be able to communicate with:
A public web application might not have direct access to these resources, but the vulnerable server may.
This creates a trust-boundary problem.
The attacker is effectively attempting to abuse the application's network position.
A typical SSRF vulnerability involves four components:
Consider an application that downloads an image from a URL.
The legitimate request might look like:
POST /profile/avatar
Content-Type: application/json
{
"image_url": "https://cdn.example.com/avatar.jpg"
}The server retrieves the image and stores it.
If the application simply trusts the supplied URL, the attacker may attempt to change the destination to another network location.
For example:
http://127.0.0.1:8080/or:
http://10.0.0.5/The exact result depends on the server's network configuration, firewall rules, URL parser, HTTP client, authentication requirements, and the service running at the destination.
That last point is important: SSRF does not automatically mean successful access to an internal service.
The vulnerability creates an unintended request capability. The actual impact depends on what that capability can reach and what those services permit.
Imagine a vulnerable endpoint:
GET /check-status?url=https://example.comThe backend performs a request to the supplied URL.
A normal request might be:
GET /check-status?url=https://example.com HTTP/1.1
Host: vulnerable-website.comThe application might internally perform:
GET https://example.comNow suppose an attacker changes the URL:
GET /check-status?url=http://127.0.0.1/admin HTTP/1.1
Host: vulnerable-website.comThe server may interpret the request as:
Server → 127.0.0.1:80If a local administrative service exists there, the application could potentially interact with it.
Whether the attacker can actually retrieve useful information depends on how the application handles the response.
SSRF is commonly discussed in two broad forms: non-blind SSRF and blind SSRF.
In a non-blind SSRF vulnerability, the application returns some or all of the remote server's response to the attacker.
Conceptually:
Attacker
|
| URL
v
Vulnerable Server
|
| Request
v
Internal Service
|
| Response
v
Vulnerable Server
|
| Response
v
AttackerThis can make exploitation easier because the attacker can directly observe the response.
For example, an application might return:
HTTP/1.1 200 OK
{
"status": "running",
"version": "..."
}The attacker may therefore learn information about an internal service.
Blind SSRF occurs when the server makes the request but does not return the destination's response to the attacker.
At first, this might appear less serious.
It is not necessarily harmless.
The attacker may still be able to cause a server-side request to an unintended destination and observe indirect effects.
Depending on the application, researchers may identify blind SSRF through:
The impact depends heavily on what the vulnerable server can reach and whether the request itself can trigger meaningful actions.
The impact of an SSRF vulnerability can range from minor to critical, depending on what the server can access. Potential consequences include:
file:///etc/passwd) or access metadata services in cloud environments (like AWS EC2), potentially leaking credentials and other secrets.Preventing SSRF requires a defense-in-depth approach:
http:// or https:// and that the hostname belongs to an expected domain.http and https. Disable schemas like file://, ftp://, gopher://, etc.The names are similar, but SSRF and CSRF are completely different vulnerabilities.
| SSRF | CSRF |
|---|---|
| Server-Side Request Forgery | Cross-Site Request Forgery |
| Abuses server-side network requests | Abuses a victim's authenticated browser |
| Server makes the request | Victim's browser makes the request |
| Often targets internal resources | Often targets application actions |
| Can expose internal services | Can cause unauthorized state-changing actions |
The distinction is important:
SSRF abuses the server's network position.
CSRF abuses a user's authenticated browser session.
Server-Side Request Forgery is fundamentally a problem of trust and network reachability.
An application accepts input from an untrusted user, but then uses that input to make a request from a trusted server environment.
That difference in network position is what makes SSRF dangerous.
A vulnerable application may unintentionally allow an external attacker to interact with resources that were designed to be reachable only from inside the infrastructure.
The severity varies significantly.
A simple SSRF might reveal information about an internal service. A more serious vulnerability could provide access to administrative APIs, cloud metadata, or internal systems. In complex environments, SSRF can also become one step in a larger attack chain.
The strongest defense is therefore not a single blacklist.
A mature SSRF defense combines:
Most importantly, applications should follow the principle of least privilege.
If a server does not need to communicate with an internal service, it should not have network access to that service in the first place.
SSRF is ultimately a reminder that server-side network access is a security capability. Once an application allows an attacker to influence that capability, every reachable destination becomes part of the application's attack surface.