What is server-side request forgery (SSRF)?

Server-side request forgery is a vulnerability where an attacker makes a server send HTTP or other requests to a destination the attacker chooses. By abusing a feature that fetches a user-supplied URL, the attacker can reach internal systems that are not exposed to the internet. This can expose internal services, cloud metadata, and other resources the server can access but the attacker normally cannot.

How does server-side request forgery work?

SSRF works when an application takes a URL or address from user input and makes a request to it without properly restricting the destination. The attacker supplies a URL pointing to internal infrastructure, such as a private IP range, loopback address, or a cloud metadata endpoint, and the server dutifully connects on their behalf. Because the request originates from inside the trusted network, it can bypass firewalls and reach services that block external access.

How do you prevent server-side request forgery?

Prevent SSRF by validating user-supplied URLs against a strict allowlist of permitted hosts and schemes rather than trying to blocklist bad ones. Resolve and check the destination address to block private, loopback, and link-local ranges, and disable unneeded URL schemes and automatic redirects. Network controls, such as segmenting the server from sensitive internal services and requiring authentication on internal endpoints, provide defense in depth.

Why is SSRF dangerous in cloud environments?

SSRF is especially dangerous in cloud environments because many providers expose an internal metadata service at a fixed private address that can return temporary credentials and instance configuration. If an attacker coerces a server into requesting that endpoint, they may harvest access keys and pivot to broader account compromise. Using metadata services that require a session token and restricting outbound access reduce this risk.

What is the difference between SSRF and CSRF?

In SSRF the vulnerable server itself is tricked into making attacker-directed requests, often reaching internal systems it can access. In CSRF the victim's browser is tricked into sending authenticated requests to a site where the user is logged in. SSRF abuses server-side trust and network position, while CSRF abuses the browser's automatic handling of a user's credentials.

What can attackers do with server-side request forgery?

With SSRF an attacker can scan and reach internal services, read cloud metadata and credentials, access internal APIs and admin panels, and sometimes retrieve files or interact with databases the server can talk to. In some cases blind SSRF still enables port scanning and service discovery even when no response is returned to the attacker. The impact depends on what the server can reach, which is why network segmentation matters.

◇ Web Security

Server-Side Request Forgery (SSRF) Explained

Server-side request forgery, or SSRF, is a vulnerability that lets an attacker coax a server into making network requests to destinations of the attacker's choosing. Instead of attacking the server directly, the adversary uses it as a proxy to reach systems it can access but the attacker cannot, such as internal services, cloud metadata endpoints, and databases behind a firewall. Because the request originates from a trusted server, it often bypasses network controls that would block an outside connection.

How SSRF Works

Many applications fetch remote resources as part of normal operation: importing a document from a URL, generating a link preview, calling a webhook, or retrieving an image for processing. When the destination is derived from user input and is not properly restricted, an attacker can substitute an internal address.

Consider a feature that fetches a URL supplied by the user:

POST /api/fetch HTTP/1.1
Host: app.example.com

url=http://169.254.169.254/

Instead of an external site, the attacker points the server at the cloud instance metadata address, a link-local endpoint reachable only from the host. The server dutifully makes the request and may return sensitive data, such as temporary cloud credentials, in the response.

Common SSRF Targets

Cloud metadata services that expose instance credentials and configuration to the host.
Internal-only services such as admin panels, message queues, and databases not exposed to the internet.
Loopback addresses that reach services bound to the server itself.
Link-local and private ranges used inside corporate or cloud networks.

Sometimes the response is not returned to the attacker. In blind SSRF, the attacker confirms the request happened through side channels, such as a DNS lookup or an HTTP callback to a server they monitor. Even without a readable response, blind SSRF can be used to map internal networks or trigger actions on internal services.

How to Prevent SSRF

SSRF is best addressed with a combination of application and network controls, because any single layer can be bypassed.

Validate Destinations with an Allowlist

Where possible, restrict outbound requests to a strict allowlist of approved domains or endpoints. Allowlisting is far more reliable than trying to block known-bad addresses, because blocklists miss alternate encodings, redirects, and obscure address formats.

Block Internal Address Ranges

Resolve the destination hostname and verify the resulting IP address is not in a private, loopback, or link-local range before connecting. Perform this check after DNS resolution and re-check on any redirect, because a hostname can resolve to an internal address even when it looks external.

Restrict Schemes and Ports

Allow only the protocols the feature actually needs, typically HTTP and HTTPS, and reject schemes like file, gopher, or ftp that can reach unexpected services. Limit destination ports to those you expect.

Do Not Follow Redirects Blindly

An allowed URL can redirect to an internal one. Either disable automatic redirect following or validate each redirect target with the same rules applied to the original request.

Protect the Metadata Service

In cloud environments, require the hardened version of the instance metadata service that mandates a signed token, and apply strict outbound rules so workloads cannot reach the metadata address unless they genuinely need it.

Segment the Network

Treat SSRF as inevitable and limit its blast radius. Place services that make outbound requests in segments that cannot reach sensitive internal systems, and enforce egress filtering so the server can only contact approved destinations. This connects to the broader risks in the OWASP Top 10.

Beware DNS Rebinding

An attacker may return a benign IP when you validate a hostname, then switch to an internal IP when the connection is made. Mitigate this by resolving the host once, validating that address, and connecting to the same address, rather than resolving twice.

Detecting and Testing for SSRF

In authorized testing, SSRF is probed by supplying URLs that point at addresses only the server can reach and watching for differences in response content, status codes, or timing. A monitored external host that records incoming DNS or HTTP requests reveals blind SSRF where no response is returned to the tester. On the defensive side, log outbound requests from any service that fetches user-supplied URLs, and alert on connections to internal ranges so that an exploited endpoint is caught quickly rather than discovered after data has been exposed.

SSRF, CORS, and the Browser

SSRF is a server-side issue and is unrelated to browser controls such as CORS, which governs cross-origin requests made by browsers. Relying on browser-enforced policies does nothing to stop a server from making a forged request, so server-side validation is essential.

Key Takeaways

SSRF makes a trusted server issue attacker-controlled requests, often reaching internal systems a firewall would otherwise protect.
Cloud metadata endpoints and internal services are prime targets, and blind SSRF works even without a readable response.
Allowlisting destinations is more reliable than blocklisting, and address checks must run after DNS resolution.
Restrict schemes and ports, avoid blind redirect following, and harden the cloud metadata service.
Network segmentation and egress filtering contain the impact when application controls are bypassed.

ssrfweb-securitycloud-securityappsecnetwork-security