Server-Side Request Forgery (SSRF) Prevention

Server-Side Request Forgery (SSRF) represents one of the most operationally dangerous classes of web application vulnerability, enabling attackers to weaponize a server's own outbound networking capability against internal infrastructure. The attack class appears as a standalone category in the OWASP Top 10 2021 list, reflecting its prevalence across cloud-native and microservices-based deployments. This page covers the classification structure, exploitation mechanics, deployment contexts, and the control-selection boundaries that distinguish effective mitigation from incomplete defenses. Security professionals navigating vendor capabilities and remediation services will find the server security providers a useful companion resource.

Definition and scope

SSRF is formally cataloged by OWASP as an attack class in which an adversary causes a server-side application to issue HTTP or network requests to a destination the attacker specifies — including internal services unreachable from the public internet. The Common Weakness Enumeration system maintains the root class under CWE-918 (Server-Side Request Forgery), with the related unintended-proxy variant cataloged under CWE-441.

The threat surface spans any application feature that fetches remote resources on behalf of a user: URL preview generators, PDF renderers, webhook configurations, file importers, and API integrations that accept caller-supplied endpoints. Cloud environments introduce a structurally amplified risk because instance metadata services — such as the AWS Instance Metadata Service (IMDS) at the fixed address 169.254.169.254 — are reachable from within the server but not from the public internet, making them a canonical SSRF target for credential harvesting.

Regulatory frameworks that mandate web application security controls treat SSRF as an in-scope vulnerability class. The Payment Card Industry Data Security Standard (PCI DSS v4.0, Requirement 6.4) requires organizations to protect public-facing web applications against known attacks, explicitly including server-side injection categories. NIST SP 800-53 Rev 5 control SI-10 (Information Input Validation) and SC-7 (Boundary Protection) together provide the formal control baseline applicable to SSRF prevention (NIST SP 800-53 Rev 5).

How it works

SSRF exploitation follows a reproducible sequence that begins with attacker-controlled input reaching a server-side HTTP client without adequate validation.

1. Input injection — The attacker supplies a crafted URL or hostname to a parameter the application passes to an internal HTTP client library (e.g., curl, urllib, HttpClient).
2. Server-side resolution — The application resolves DNS and opens a TCP connection from the server's network context, bypassing perimeter firewalls that block the attacker's external IP.
3. Response reflection or blind execution — In reflected SSRF, the server returns the fetched content to the attacker. In blind SSRF, no response body is returned, but the request still executes — detectable through out-of-band channels such as DNS callback infrastructure.
4. Privilege escalation or lateral movement — The attacker uses the server as a proxy to query internal APIs, metadata endpoints, or adjacent services, harvesting credentials, tokens, or sensitive configuration data.

The distinction between reflected SSRF and blind SSRF carries direct consequences for detection and impact assessment. Reflected SSRF yields immediate data exfiltration; blind SSRF is harder to detect but still enables port scanning of internal networks, triggering of internal state-changing requests, and metadata service enumeration. OWASP's SSRF Prevention Cheat Sheet treats both as requiring equivalent preventive controls because exploitation impact does not depend on response visibility.

Common scenarios

SSRF vulnerabilities appear across a consistent set of application patterns in production deployments.

Cloud metadata enumeration is the most impactful scenario in AWS, Azure, and GCP environments. A single successful SSRF request to http://169.254.169.254/latest/meta-data/iam/security-credentials/ can return temporary IAM credentials granting broad AWS account access. AWS partially mitigated this at the infrastructure level with IMDSv2 (Instance Metadata Service Version 2), which requires session-oriented PUT requests — but application-layer SSRF controls remain necessary because the server itself can be forced to issue the required PUT.

Webhook and integration endpoints expose SSRF attack surface in SaaS platforms, CI/CD pipelines, and API gateway configurations where operators supply callback URLs. A misconfigured webhook processor that fetches the supplied URL without allowlist validation is structurally vulnerable regardless of the underlying framework.

PDF and image rendering services that accept remote URLs to embed content are a well-documented vector. Server-side headless browsers and document converters execute full HTTP stacks, making them capable of reaching internal services that a standard HTTP client would also reach.

Internal API proxying in microservices architectures creates SSRF risk when a public-facing service accepts a target or service parameter and routes requests internally without strict service-name allowlisting. The OWASP API Security Top 10 (API8:2023 — Security Misconfiguration) covers this pattern explicitly.

Decision boundaries

Selecting the appropriate SSRF prevention controls requires distinguishing between scenarios based on application architecture, network topology, and deployment environment. The server security provider network purpose and scope page provides broader context on the service categories that address these control domains.

Allowlist vs. denylist validation is the foundational decision. Denylist approaches — blocking RFC-1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and loopback addresses — are considered insufficient as standalone controls by OWASP because attackers can bypass them through DNS rebinding, IPv6 representations, decimal IP encoding, and URL-encoded characters. Allowlist validation restricting permitted schemes (HTTPS only), hostnames, and port ranges provides a structurally stronger boundary.

Network-layer egress filtering complements application-layer validation. Configuring server-side firewall rules or security groups to block outbound connections to RFC-1918 ranges and metadata service IPs provides defense-in-depth. NIST SP 800-41 Rev 1 (Guidelines on Firewalls and Firewall Policy) establishes the principle that egress filtering should be enforced independent of application behavior.

DNS resolution control is a specialized boundary relevant where DNS rebinding is a concern: resolving the hostname once, validating the resulting IP against the allowlist, and using that resolved IP for the actual connection — rather than re-resolving at connection time — closes a rebinding window that allowlist checks alone leave open.

IMDSv2 enforcement in AWS environments is a discrete configuration decision with a binary outcome: instances configured to require IMDSv2 reject metadata requests that do not include a session token, reducing — though not eliminating — cloud metadata SSRF impact. AWS documentation and the CIS Amazon Web Services Foundations Benchmark both treat IMDSv2 enforcement as a mandatory baseline control.

Organizations evaluating service providers for SSRF-specific penetration testing, secure code review, or application firewall configuration can reference the structured providers available through the how to use this server security resource page for guidance on provider categories and qualification standards.