What Is Server-Side Request Forgery (SSRF)?

Updated on November 20, 2025

Server-Side Request Forgery (SSRF) is a web application vulnerability that allows an attacker to make the server-side application send an HTTP request to an arbitrary domain. This malicious request is sent from the vulnerable server itself. This bypasses traditional perimeter defenses and exploits the server’s internal network access and trusted identity.

SSRF attacks often target internal systems, like internal Application Programming Interfaces (APIs) or cloud metadata services. These systems are normally inaccessible from the public internet. This makes SSRF a critical threat to modern, cloud-based architectures.

This guide will explain the core concepts of SSRF, how it works, and its primary defense mechanisms. We will provide the technical details needed for web developers, security engineers, and cloud architects to understand and mitigate this vulnerability.

Definition and Core Concepts

SSRF is a vulnerability where an application’s internal code is tricked into executing an unexpected request. This request targets an external or internal resource defined by user-supplied input. The application fails to properly validate or sanitize the target URL.

The request is made by the server, using the server’s own trusted privileges. This is different from a client-side attack, where the request originates from the user’s browser. Understanding this distinction is key to grasping the threat SSRF poses.

Foundational concepts

• Resource Fetching: The legitimate function that the attack exploits. This typically involves functions that retrieve data from an external URL, like fetching an image or processing a webhook.
• Internal Network Access: The key advantage for the attacker. The vulnerable server can reach internal services and private IPs that are not exposed to the public internet.
• Trust Exploitation: The attacker exploits the inherent trust that internal services place in requests originating from the same internal network.
• URL Sanitization/Validation: The failure point. The application must strictly validate that the user-supplied URL points only to allowed, public destinations.

How It Works: Exploitation Phases

SSRF exploitation typically follows a two-stage process: finding the vulnerability and targeting internal resources. An attacker must first identify a part of the application that accepts a URL as input and processes it. Once confirmed, the attacker can use this vulnerability to probe the internal network.

Vulnerability Identification

An attacker locates an endpoint that accepts a URL as input. Common examples include an image importer, a PDF generator, or a parameter like image_url=. The attacker tests this input by supplying arbitrary URLs to see if the server processes the request.

For example, a test with a URL pointing to the local host (http://127.0.0.1/) can reveal whether the server attempts to connect. The server’s response or error message often confirms the vulnerability.

Targeting Internal Services (Port Scanning/Data Theft)

Once the vulnerability is confirmed, the attacker can direct the server to request sensitive internal endpoints. This allows the attacker to map the internal network and exfiltrate data.

• Internal IPs: The attacker directs requests to non-routable private IP ranges, such as 10.x.x.x or 192.168.x.x. This helps discover other internal systems.
• Cloud Metadata Services: The attacker directs requests to specific cloud metadata endpoints, like http://169.254.169.254/latest/meta-data/. This is done to steal security credentials, access keys, and other sensitive configuration data from cloud providers.
• Port Scanning: The server is used to scan internal network ports. This is done by sequentially hitting internal IP addresses on different ports and observing the response time or error codes to identify active services.

Key Features and Components

SSRF vulnerabilities have distinct features that make them particularly dangerous. These features stem from the fact that the malicious request originates from a trusted server within the network perimeter. Understanding these components is essential for both defense and threat modeling.

Bypassing Firewalls

The attack bypasses perimeter firewalls because the request originates internally from a legitimate, trusted application. This makes traditional network security measures ineffective against SSRF. The firewall sees a request from a trusted source and allows it to proceed.

Protocol Wrappers

Attackers can exploit server-side URL parsing libraries by using different protocol wrappers. Wrappers like file://, ftp://, or dict:// can be used to read local files or interact with other internal services. This expands the attack surface beyond simple HTTP requests.

Blind SSRF

Blind SSRF is a variant where the attacker cannot directly see the response of the forged request. However, they can still infer information. This is often done by observing time delays or indirect changes to the application’s state, which can indicate whether a port is open or a service is responsive.

Use Cases and Applications (Attacker Perspective)

From an attacker’s perspective, SSRF is a high-impact vulnerability. It facilitates deep access into a network and can be the first step in a larger attack chain.

Cloud Credential Theft

Stealing temporary security credentials from cloud providers like AWS, Azure, and GCP is a primary goal. By accessing the internal metadata service, an attacker can gain credentials that grant access to other cloud resources. This is the most common and damaging SSRF use case.

Internal Port Scanning

SSRF allows an attacker to map the internal network architecture. This helps them find other vulnerable systems, such as development servers, monitoring tools, or unsecured databases. This information is invaluable for planning further attacks.

Webhooks and Service Integration Attacks

Attackers can exploit webhooks where a server makes a request to a user-supplied callback URL. This allows the attacker to pivot into the server’s internal network. Any service that integrates with third-party systems via URLs is a potential target.

Advantages and Trade-offs (Defense)

Mitigating SSRF requires a proactive and disciplined approach to development. The primary defense is straightforward, but its implementation can be challenging in complex applications.

Advantages (Defense)

The most effective mitigation is to enforce strict, centralized validation of all user-supplied URLs. Implementing an allow list (also known as a whitelist) of permitted domains is highly effective. This ensures that the server can only make requests to approved, known-safe destinations.

Trade-offs (Defense)

Complex applications that require dynamic access to many different external resources can be challenging to restrict effectively. Developers must be disciplined enough to apply validation to every single resource-fetching endpoint. Without consistent application of security controls, a single vulnerable endpoint can compromise the entire system.

Key Terms Appendix

• Cloud Metadata Service: An internal API used by cloud environments to provide configuration and credentials to virtual machine instances.
• URL Sanitization: The process of cleaning user input to prevent a malicious URL from being executed by the server.
• Same-Origin Policy (SOP): A browser security mechanism that restricts how a document or script loaded from one origin can interact with a resource from another origin. SOP is irrelevant to SSRF because the attack is executed from the server, not the browser.
• Port Scanning: The process of sequentially hitting ports on a server to determine which services are active.