Server-Side Request Forgery Prevention Checklist for Secure Code

Understanding the Server-Side Request Forgery Threat Model

Server-side request forgery occurs when an application fetches a URL provided by a user without verifying its safety. The server becomes a proxy for the attacker, sending requests on their behalf. This mechanism allows attackers to bypass firewalls that protect internal networks, as the request originates from a trusted server. You must treat every user-supplied URL as hostile input. The server’s network position grants it access to resources that external attackers cannot reach directly.

Imagine a web application that fetches images from user-provided links. An attacker supplies a link to an internal database server. The application fetches the data and returns it to the attacker. This bypasses network segmentation. The risk extends beyond data theft. Attackers can use the server to scan internal networks or launch attacks against other internal services. Understanding this pivot capability is fundamental to designing effective defences.

Network Access Control and IP Filtering

This section covers the primary controls for restricting where the server can send requests. You must prevent the application from connecting to internal or reserved IP ranges. These ranges include private networks and loopback addresses. Blocking these ranges stops attackers from accessing internal services directly.

• Block private IPv4 ranges: prevents access to internal corporate networks and databases.
• Block private IPv6 ranges: stops evasion attempts using newer address formats.
• Block loopback addresses: prevents the server from querying itself or local services.
• Block link-local addresses: stops access to devices on the same local network segment.
• Block carrier-grade NAT ranges: prevents access to large reserved blocks often used in evasion.

Relying solely on blocking private IPs is insufficient. Attackers can use open proxies or DNS rebinding techniques to bypass these filters. You must combine IP filtering with other controls. DNS rebinding involves changing the IP address of a domain after the initial check. This allows an attacker to pass the initial validation and then resolve to an internal IP.

URL Validation and Protocol Enforcement

Strict validation of the URL structure and protocol is necessary to prevent protocol-based attacks. Some applications accept multiple protocols, such as HTTP, HTTPS, FTP, and Gopher. Each protocol has different security properties. Allowing unsafe protocols expands the attack surface significantly.

• Enforce HTTPS only: prevents man-in-the-middle attacks during the fetch process.
• Block file:// protocol: stops attackers from reading local files on the server.
• Block gopher:// protocol: prevents interaction with legacy services that may execute commands.
• Block dict:// protocol: stops access to dictionary services that may leak information.
• Validate URL syntax: ensures the URL is well-formed before processing.

You must parse the URL carefully. Some parsers handle edge cases differently. A malformed URL might be interpreted differently by the validation library than by the underlying network stack. This discrepancy can lead to bypasses. Always use a trusted library for URL parsing. Verify that the parsed components match the expected values. Do not trust the string representation of the URL alone.

Redirect Handling and Cloud Metadata Protection

HTTP redirects allow a server to follow a chain of URLs. Attackers use this to bypass initial validation checks. The initial URL might be valid, but the redirect points to an internal resource. Disabling automatic redirect handling forces the application to stop at the first URL.

• Disable automatic redirects: prevents chaining to internal targets via external URLs.
• Block cloud metadata endpoints: stops credential theft from cloud instances.
• Validate redirect targets: if redirects are allowed, check each hop against the allowlist.
• Limit redirect depth: prevents infinite loops and resource exhaustion attacks.

Cloud metadata services provide credentials and configuration data to instances. These services are often accessible only from the instance itself. Server-side request forgery can exploit this to steal credentials. You must block access to known metadata endpoints. These endpoints include those for Amazon Web Services, Google Cloud, and Microsoft Azure. Blocking these specific IPs and paths is critical for cloud-hosted applications.

Implementation Strategy and Testing

Implementing these controls requires a layered approach. No single control is sufficient. You must combine network controls, input validation, and application logic. Testing is essential to verify that the controls work as intended. Fuzz testing can help identify edge cases in URL parsing and validation logic.

• Use allowlists for domains: restricts requests to known safe destinations.
• Implement time-outs: prevents denial-of-service attacks via slow responses.
• Log all requests: aids in detection and incident response.
• Regularly update dependencies: ensures you have the latest security patches.

Consider integrating these checks into your threat modeling process. Identify where user input flows into network requests. Assess the risk of each flow. Prioritise controls based on the potential impact. A risk-based vulnerability management approach helps allocate resources effectively. You should also consider the vulnerability lifecycle when planning updates. Dependencies must be kept current to avoid known flaws.

See also: CORS Misconfiguration Recovery: Immediate Response and Remediation Steps

Reviewing Related Security Concepts

Server-side request forgery often intersects with other web application vulnerabilities. Understanding these relationships helps in designing a holistic defence. For instance, LDAP injection can be used in conjunction with SSRF to access directory services. Vulnerability lifecycle management ensures that discovered flaws are tracked and remediated. Dependency updates are critical for maintaining the security of third-party libraries.

EPSS score can help prioritise which vulnerabilities to fix first. Exploit kits often bundle multiple attack vectors, including SSRF. Fuzz testing can reveal unexpected behaviours in URL handling. Threat modeling provides a structured way to identify potential SSRF vectors. By integrating these concepts, you build a more resilient application.

Key takeaways

• Allowlist specific domains rather than blocking known bad patterns to prevent evasion.
• Disable HTTP redirects to stop attackers from chaining requests to internal targets.
• Block access to cloud metadata endpoints to prevent credential theft from cloud instances.

Frequently asked questions

Why is allowlisting better than blocklisting for SSRF?

Allowlisting restricts access to known safe destinations, preventing access to any new or unknown internal targets that attackers might discover. Blocklisting relies on knowing all bad targets, which is impossible.

Can DNS rebinding bypass IP filtering?

Yes, DNS rebinding changes the IP address of a domain after the initial validation, allowing the request to resolve to an internal IP address that was not checked.

Should I disable all HTTP redirects?

Disabling automatic redirects is the safest approach. If you must allow them, validate every redirect target against your allowlist and limit the depth of redirection.

How do I protect cloud metadata endpoints?

Block access to known cloud metadata IP addresses and paths at the application level. Ensure your firewall rules do not allow outbound traffic to these specific internal ranges.

How this guide was produced: written by the TechWire Beat editorial team with AI assistance, checked against the public references listed below, and reviewed when the facts change. See our editorial policy or report an error.