Server-side request forgery, or SSRF, is a vulnerability that enables malicious actors to make a vulnerable web server send crafted requests to other systems. Recognized in the OWASP Top 10 as a significant application security risk, SSRF can expose sensitive information and create opportunities for much more serious attacks (now in the “Broken Access Control” category).
This article explains how SSRF works, how such vulnerabilities can be detected, and which measures help prevent SSRF in web applications.
Introduction to server-side request forgery (SSRF)
Web applications often initiate requests between HTTP servers. These requests are commonly used to retrieve remote resources, such as software updates, or to import metadata from a URL or from another web application. Server-to-server communication is not inherently dangerous. However, when it is implemented incorrectly, it can expose the server to server-side request forgery, commonly known as SSRF.
An SSRF vulnerability appears when data controlled by a user is used to construct the destination URL. Once this happens, an attacker may modify a parameter in the vulnerable application and cause the affected server to create or control requests on the attacker’s behalf.
A web application may access external resources such as internal services or an RSS feed hosted on another website. For example, a developer might use the following URL to fetch a remote feed:
https://example.com/feed.php?url=externalsite.com/feed/to
If an attacker can replace the url parameter with localhost, meaning the loopback interface, local resources hosted on the server may become visible. This creates a server-side request forgery risk.
When attackers can influence the destination of server-side requests, a wide range of offensive actions becomes possible. They may be able to:
- Abuse the trust relationship between the vulnerable server and other system
- Bypass IP allowlisting
- Circumvent host-based authentication mechanisms
- Access web resources and valuable assets that are not publicly reachable, such as metadata APIs in AWS environments or trace.axd in ASP.NET
- Scan ports on the internal network connected to the server
- Read files from the web server
- View status pages and interact with APIs as if the requests came from the web server
- Obtain sensitive details, such as the IP address of a web server operating behind a reverse proxy
SSRF in the OWASP Top 10
Server-side request forgery is a widely recognized vulnerability and has repeatedly appeared in the Open Web Application Security Project’s list of the ten most critical web application security risks. In the OWASP Top 10 for 2021, SSRF received its own dedicated category for the first time: A10:2021 Server-Side Request Forgery. It was added as a separate category based on feedback from a community survey. Currently, in the OWASP Top 10 (2025), this category is included under “Broken Access Control.”
As modern web applications become more complex and more interconnected, fetching a URI has become a basic operation required for delivering both content and functionality. As the number of server-side requests has increased, SSRF vulnerabilities have also become more frequent. Their potential impact has also grown because cloud services and complex cloud-based application architectures are now widely used. In such environments, a compromised server may give attackers access to web infrastructure and cloud data sources.
Typical exploitation of a server-side request forgery vulnerability
In a common SSRF scenario, an external attacker attempts to access an internal server. Direct requests are not possible because they are blocked by a firewall. Instead, the attacker exploits an SSRF vulnerability and routes the attack through a vulnerable web server.
- The attacker sends a forged request to a web server that is vulnerable to SSRF and located on the same internal network as the intended target.
- The vulnerable web server then forwards the attacker-controlled request to the victim server, bypassing the firewall.
- The victim server responds to the web server with the requested data.
- If the specific SSRF flaw allows it, the response data is returned to the attacker. In many cases, however, the attacker must extract or infer the information through other methods, including out-of-band techniques.
Why is server-side request forgery dangerous?
Many web vulnerabilities directly affect the system being targeted. SSRF is different because it allows attackers to use the affected server as an intermediary that sends requests to a third system. An SSRF attack may not always cause immediate damage by itself. However, it can give malicious hackers access to internal systems that were never intended to be reachable from the Internet. This makes SSRF dangerous for several reasons.
SSRF abuses the trust relationship between internal systems
A core security principle is to keep the attack surface as limited as possible at every level. Inside internal networks, this usually means that access to specific ports or actions is restricted to selected, allowlisted machines. To support data exchange and administrative operations while maintaining security, servers often have trust relationships with certain other systems.
At the network level, this trust may mean that a firewall permits access to particular ports only when the request comes from the same local network or from an explicitly trusted IP address. At the software level, local machines may be trusted implicitly. For example, some administrative functions may not require authentication if the request comes from 127.0.0.1 or from inside the internal network. This adds a degree of physical security. Even valid credentials are not enough if the attacker lacks access to the local network.
By exploiting an SSRF vulnerability, an attacker can bypass these restrictions and interact with other servers that trust the compromised machine. This may involve sending data queries or crafting malicious requests to ports that are not accessible from the external network. Through forged server-side requests, an external attacker can perform actions on the target server that would otherwise be impossible from outside.
SSRF allows attackers to scan local or external networks
A server-side request forgery vulnerability may allow attackers to scan local or external networks connected to the vulnerable server. Direct data extraction is often not possible. However, attackers can rely on page load times, error messages, or service banners to determine indirectly whether a targeted service responds or whether a specific port is open.
Example: How to scan a network via an SSRF vulnerability
Consider a website with a service that fetches JPEG images from a remote location in order to determine their dimensions. As a security measure, the service checks whether the response from the remote source includes a Content-Type HTTP header with the value image/jpeg. If the header is missing or contains a different content type, the service assumes that another image format was provided and returns the error message Please provide JPEG images only. If the service cannot connect to the remote source, it returns No image found!. The following examples show how different inputs can change the service response. And allow an attacker to determine whether a host is available.
- If the request is: https://victim.com/image.php?url=https://example.com/picture.jpg the service returns the image height and width. This means the file is a valid image with the expected Content-Type header.
- If a different HTTP request is used and the server receives an HTML file instead of an image, for example:
https://victim.com/image.php?url=https://example.com/index.html. The response becomes Please provide JPEG images only, because the supplied page has the wrong Content-Type header, namely text/html instead of image/jpeg. - For an invalid URL such as: https://victim.com/image.php?url=https://example.invalid/ the service returns Image not found, which indicates an error while fetching the remote resource.
Once the application’s behavior for different inputs is understood, the logic can be abused. A valid URL with a missing or incorrect Content-Type header returns the error Please provide jpeg images only. The following request can then be sent using an internal URL:
https://victim.com/image.php?url=127.0.0.1:3306
If the response is Image not found, there is no response from host 127.0.0.1 on port 3306. If the response is Please provide jpeg images only, the internal server did respond, which means a service is running on that port. In this way, the vulnerable web application can be used to probe internal IP addresses and ports until a complete scan is built. In practice, this type of SSRF vulnerability enables port scanning without using a traditional port scanner.
SSRF can expose files and internal resources on the server
If the content of a remote resource is rendered directly on a page, attackers may be able to read file contents. For example, consider a web service that removes all images from a supplied URL and then formats the remaining text. To achieve this, it takes the response body for the given URL and applies text formatting to it.
If the service is vulnerable to SSRF and accepts a file:// URL instead of only http:// or https://, local files may be read from the file system. On a UNIX-based system, supplying file:///etc/passwd could display the contents of the passwd file. The same technique could also be used to view the source code of the vulnerable web application.
What are the potential impacts of SSRF attacks?
As the examples show, the direct result of exploiting a server-side request forgery vulnerability is almost always information disclosure. Attackers gain useful information about systems and resources that should not be accessible to them. The indirect consequences, however, may be far more serious. SSRF can allow malicious actors to:
- Use the vulnerable server as a scanner for ports and IP addresses across internal and external systems
- Interact with protocols such as Gopher, if enabled, to conduct further reconnaissance
- Identify the IP addresses of servers operating behind a reverse proxy
- Achieve remote code execution
Because SSRF mainly acts as an access path for additional probing and attacks, many other outcomes are possible. The final impact depends on how the vulnerable web application processes responses from remote resources. When SSRF is combined with other vulnerabilities under favorable conditions for the attacker, the consequences can be severe.
Preventing server-side request forgery
To prevent SSRF vulnerabilities in web applications, the recommended approach is to use an allowlist of permitted domains and protocols for remote resources fetched by the web server. More broadly, user input should not be used directly in functions that can send requests on behalf of the server. Sanitizing and filtering input is always useful, but it should not be treated as the only defense. Covering every possible bypass scenario is practically impossible.
Attackers have many techniques for bypassing URL filtering, including:
- Using encoded IP addresses that are translated into an internal network IP:
- 1 → same as localhost
- 123.123.123 → same as localhost
- Supplying hostnames that resolve to internal IP addresses
- Bypassing hostname blacklists by adding dots at the end of the hostname
These are only a few examples from the many bypass methods available to attackers. For this reason, the safest practice is to avoid passing user-controlled input into functions that issue requests on behalf of the server.
Identifying SSRF vulnerabilities in your web applications
Modern dynamic application security testing (DAST) solutions such as Invicti (based on Acunetix and Netsparker) can detect many server-side request forgery vulnerabilities during application’s runtime, including out-of-band ones.
For earlier detection during the development process, Static Application Security Testing (SAST) tools, like from Mend.io, are very handy.
Invicti and Mend.io have a seamless integration for centralized vulnerability management, if you would like to test any of these solution for free, please leave your contact details in the form below.
