Server-Side Request Forgery (SSRF): Risks, Attack Techniques, and Protection

What is Server-Side Request Forgery (SSRF)?

Server-Side Request Forgery (SSRF) is a security vulnerability that allows an attacker to trick a server into making unauthorized requests to internal or external locations.

This usually happens in applications where user input is used to fetch resources—such as images, files, or web pages. An attacker can manipulate that input to make the server send requests to internal services or restricted endpoints. Because the request comes from the server itself, it may bypass network restrictions and reach systems not exposed to the internet.

For example, SSRF can be used to access internal URLs like http://localhost/admin or sensitive cloud metadata endpoints like http://169.254.169.254. These requests can leak internal data, cloud credentials, or even allow attackers to pivot deeper into the infrastructure.

SSRF attacks are particularly dangerous in cloud environments, where internal services might be highly interconnected, and requests from within the network are often trusted, making it easier for attackers to escalate their privileges or leak critical information.

 

How Server-Side Request Forgery Vulnerabilities Arise

SSRF is typically the result of improper validation or sanitization of user inputs that the server uses to make HTTP or other network-based requests. Here are some common causes:

1. User-Controlled URLs Without Whitelisting: Applications that accept URLs as input (for image previews, webhooks, file imports, etc.) often trust the provided address. If there are no proper domain whitelisting or protocol restrictions, attackers can abuse SSRF vulnerabilities to force the server to connect to arbitrary locations, including internal services such as 127.0.0.1 or http://internal-db.
2. Misconfigured Third-Party Libraries: Some third-party tools used for PDF generation, screenshots, or content fetching rely on user-supplied URLs without safeguards. Attackers can exploit these integrations if they allow requests to internal networks or insecure schemes like file:// or gopher://.

 

Tools like wkhtmltopdf, headless browsers, or even curl-based libraries can introduce SSRF if they take unvalidated input. Also, misuse of schemes such as file:// or gopher:// can escalate the attack to Local File Read or arbitrary command execution, respectively.

 

1. Insufficient SSRF Protections in Cloud Platforms: Cloud providers often expose sensitive APIs or metadata on internal IPs. Without explicit safeguards, SSRF flaws in cloud-hosted applications can be exploited to extract IAM tokens or modify instance configurations.
2. Open Redirects and DNS Rebinding: SSRF can also arise when applications follow redirects blindly. Attackers may host a redirector that resolves to an internal IP after DNS changes. Once the server follows the redirect, it unknowingly accesses internal systems, bypassing firewall protections.

 

3 Types of SSRF Attacks

SSRF attacks can be categorized based on the target of the forged request and the attacker’s goals. Below are the primary forms:

1. Basic SSRF (External)

The attacker uses the server to send requests to an external site they control. This can be used to:

• Bypass IP-based access controls
• Hide the source of an attack (since it originates from a trusted server)
• Steal server environment details through crafted responses

2. Blind SSRF

In this case, the attacker doesn’t see the response directly but can infer behavior based on side effects. This includes:

• Timing differences (slow response = valid internal resource)
• DNS lookups (to detect if the server resolved a domain)
• Out-of-band (OOB) interactions like HTTP/DNS callbacks

Blind SSRF often requires external monitoring tools like Burp Collaborator to confirm exploitation.

3. Internal SSRF

Here, the attacker forces the server to interact with internal IP ranges or services such as:

• http://localhost:8080/admin
• http://169.254.169.254/latest/meta-data/
• Internal Kubernetes or Redis services

This form is especially dangerous because internal systems often assume local traffic is trusted and don’t enforce strict authentication.

 

Risks and Impact of SSRF Vulnerabilities

SSRF is considered highly critical due to its potential to escalate quickly. The risks include:

1. Access to Internal Resources

SSRF can be used to target internal applications not exposed to the internet, such as admin panels, databases, cloud service APIs, and container orchestrators. These systems often lack authentication because they assume only internal users or services can reach them.

2. Credential Theft

In cloud environments like AWS, Google Cloud, or Azure, metadata services exposed on 169.254.169.254 provide temporary access tokens and configuration data. SSRF can allow attackers to steal these tokens and escalate privileges to other services including S3, EC2, RDS and more.

3. Port Scanning and Enumeration

By sending requests to internal IPs and analyzing the responses (or response times), attackers can map out services running inside the organization. This internal reconnaissance helps them plan further attacks such as lateral movement and privilege escalation.

4. Remote Code Execution (RCE)

In rare but high-risk cases, SSRF may lead to code execution if the targeted internal service accepts payloads or command injections. This is especially true for services like Jenkins, Redis, or vulnerable APIs.

Explore Remote Code Execution in depth.

5. Data Exfiltration

SSRF can be combined with other flaws like SSRF-to-XSS or SSRF-to-SSJI (server-side JavaScript injection) to exfiltrate sensitive data, tokens, logs, and configurations directly to the attacker’s server.

Learn more about data exfiltration techniques.

 

How to Detect Server-Side Request Forgery Vulnerabilities

Detecting SSRF requires both automated scanning and targeted testing. Here are the most effective methods:

1.Validating User Inputs

Security testing tools, such as Indusface WAS, can be used to simulate attacks by injecting payloads like http://127.0.0.1, file://, or DNS-interaction domains to check if the application makes unauthorized outbound requests.

Responses, redirects, and error codes reveal SSRF behavior.

2. Out-of-Band (OOB) Detection

Use DNS logging services (e.g., Burp Collaborator) to observe DNS or HTTP callbacks when injecting controlled domains. Even blind SSRFs can be detected this way, as any outbound request confirms server-side execution.

3. Log Analysis

Look for anomalies such as:

• Unusual outbound connections in network logs
• Access to internal IPs or restricted metadata services
• Repeated 5xx errors from internal APIs

Centralized logging and alerting systems help detect SSRF attempts in real time.

4. Manual Pen Testing

Experts often identify SSRF through crafted payloads and behavioral analysis, especially in scenarios where automated tools fail due to redirects, custom response codes, or unconventional error messages.

 

6 Best Practices to Prevent SSRF Vulnerabilities

Preventing SSRF requires a layered approach—from input validation to network-level controls. Here’s how to secure your apps effectively:

1. Validate and Whitelist URLs

If your application must accept URLs, enforce strict allowlists. Only permit domains or IPs that are necessary for functionality. Reject any local, loopback, or private IP addresses (e.g., 127.0.0.1, 169.254.0.0/16, 10.0.0.0/8).

Use DNS resolution to check if a domain maps to a restricted IP, and re-check post-resolution to avoid DNS rebinding.

2. Restrict Outbound Traffic

Configure firewalls or outbound proxies to block requests to sensitive internal ranges. Limit the server’s ability to initiate external connections unless absolutely required.

3. Use Secure Libraries and Frameworks

Avoid using low-level libraries for fetching external resources unless you have full control over request logic. Use mature frameworks that offer built-in SSRF protections or wrappers that sanitize inputs.

4. Disable Unused Protocols

Block access to unsupported or dangerous URL schemes like file://, ftp://, gopher://, and dict://. Limit the application to only support http:// and https:// if necessary.

5. Monitor and Alert on Anomalies

Set up alerts for high-risk outbound requests, metadata IP access, or connection attempts to restricted IP ranges. Combine application logs with network telemetry to catch SSRF attempts early.

6. Implement Web Application Firewall

While SSRF (Server-Side Request Forgery) originates from within the server, a Web Application Firewall (WAF) plays a crucial role in detecting and blocking suspicious external inputs that could trigger SSRF vulnerabilities.

AppTrana WAF continuously monitors incoming traffic and inspects request payloads for malicious patterns, such as attempts to inject internal URLs (127.0.0.1, 169.254.169.254, etc.) or unsupported protocols (file://, gopher://). This real-time filtering helps block SSRF attempts before they reach the application.

When a specific SSRF vector is discovered in an app, the WAF can be configured (often by a security team) to block that exact behavior without needing to change the application code.