OWASP API 7 : Server Side Request Forgery (SSRF)


This year we have Server Side Request Forgery (SSRF) as No.7 at OWASP API Top 10 which replaces OWASP Top 10 API 2019: Security Misconfiguration. SSRF is a security vulnerability that arises when an application fetches a remote resource without adequately verifying and validating user-supplied URLs. This flaw can enable attackers to manipulate the application into sending malicious requests to unintended destinations, even if the target application is protected by firewalls or VPNs.

The prevalence and significance of SSRF vulnerabilities have increased in recent years due to evolving practices in application development. Developers frequently incorporate functionality that relies on user input, such as webhooks, file fetching from URLs, custom Single Sign-On (SSO) solutions, and URL previews. Moreover, with the growing adoption of cloud services, containerization technologies like Kubernetes and Docker, management and control interfaces are often exposed over HTTP, making them prime targets for SSRF attacks.

What is SSRF?

SSRF is a security vulnerability that arises when an application processes a user-supplied URL to make HTTP requests to external resources, and the application fails to properly validate or sanitize the user-provided input. As a result, an attacker can manipulate these URLs to trigger unintended requests to internal or external systems, potentially causing significant harm.

Key Aspects of SSRF:

  • Inadequate URL Validation: The heart of SSRF is the lack of robust validation and sanitization of user-supplied URLs. An attacker can insert URLs pointing to resources they should not have access to.
  • Scope of Impact: SSRF can affect a wide range of applications and systems, from web applications to APIs, cloud services, and more.
  • Unintended Access: Attackers can force the application to access internal network resources or resources on the internet, potentially circumventing security controls and firewalls.

Common Causes of SSRF:

  • User-Provided Input: SSRF often occurs when applications accept user-provided URLs, such as in file uploads, URL previews, or API endpoints that fetch data from external sources.
  • Blind Trust: The application blindly trusts the user-supplied URL without verifying its authenticity, leading to potential exploitation.


Exploiting SSRF can result in a range of consequences, including:

  • Internal Services Enumeration: Attackers can conduct port scanning within the internal network to identify open and closed ports, potentially exposing network vulnerabilities.
  • Information Disclosure: Sensitive data may be inadvertently disclosed, providing attackers with valuable information about the internal infrastructure.
  • Bypassing Security Mechanisms: SSRF can allow attackers to circumvent firewalls, VPNs, and other security measures by coercing the application into accessing internal resources.
  • Denial of Service (DoS): Attackers can overwhelm the server by triggering a large number of SSRF requests, causing it to become unresponsive or even crash.
  • Proxy for Malicious Activities: In some cases, attackers can use the compromised server as a proxy to obscure their own malicious activities, making it difficult to trace the source of the attacks.

To illustrate these points, here are two examples of SSRF attacks:

Social Network Profile Picture Upload: A social network allows users to upload profile pictures either by uploading an image file or providing a URL. An attacker submits a malicious URL as their profile picture, causing the application to make an API call to that URL. By carefully observing the response time, the attacker can determine whether certain internal network ports are open or closed, potentially revealing network weaknesses.

Security Product Webhook Integration: A security product integrates with external systems via webhooks. When creating a new webhook, the API backend sends a test request to the provided URL and displays the response to the user. An attacker can exploit this process by making the API request a sensitive resource, like an internal cloud metadata service that exposes credentials. By examining the response, the attacker can gain access to the cloud environment’s credentials.


To mitigate SSRF vulnerabilities, the Open Web Application Security Project (OWASP) recommends the following best practices:

  • Isolation of Resource Fetching: Isolate the mechanism responsible for fetching resources, ensuring it can only access remote resources rather than internal ones.
  • Allow Lists: Use allow lists to specify which remote origins, URL schemes, ports, and accepted media types are permitted for resource fetching. This restricts the potential attack surface.
  • Disable HTTP Redirections: Prevent HTTP redirections, as attackers can abuse them to redirect requests to unintended destinations.
  • Use a Well-Tested URL Parser: Employ a robust and well-maintained URL parser to avoid issues stemming from URL parsing inconsistencies and edge cases.
  • Input Validation and Sanitization: Implement stringent input validation and sanitization measures to filter out malicious URLs supplied by clients.
  • Controlled Responses: Avoid sending raw responses to clients to prevent unintentional information disclosure and limit the potential impact of SSRF attacks.

Leave a Reply