What Is SSRF? Server-Side Request Forgery

SSRF, short for Server-Side Request Forgery, is a web application vulnerability that lets an attacker make a server send requests to destinations the attacker should not be able to reach directly. In practice, SSRF can expose internal services, cloud metadata endpoints, localhost-only applications, or private APIs because the vulnerable server makes the request on the attacker’s behalf.

For related background, it also helps to read what is api security and what is zero trust, since SSRF often becomes more dangerous when internal trust boundaries are weak.

SSRF definition

SSRF happens when an application accepts a user-controlled destination, usually a URL or host, and then performs a server-side request without sufficiently restricting where that request can go.

Common examples include features that:

Fetch remote images
Generate URL previews
Process webhooks
Import files from a link
Connect to external APIs
Render documents from remote content

If the app trusts user input too much, an attacker may be able to point the server at an internal or sensitive target instead of a legitimate external one.

How SSRF works

SSRF usually appears anywhere an application makes outbound connections on behalf of the user.

A simple example

Imagine an app has a feature that downloads an image from a URL a user provides. If the app accepts any destination, an attacker might supply a URL pointing to:

127.0.0.1
An internal IP address
A private admin panel
A database admin console
A cloud metadata endpoint
Another internal API

The attacker is not accessing those systems directly. They are getting your server to do it for them.

Why that matters

Application servers often have access that outside users do not. They may be able to reach:

Internal dashboards
Localhost-only services
Private microservices
Container or orchestration endpoints
Cloud instance metadata services
Back-end admin interfaces

That means SSRF can bypass assumptions like “this service is safe because it is not exposed to the internet.”

A typical SSRF flow

A common SSRF attack path looks like this:

The attacker finds a feature that makes outbound requests
They supply a crafted URL or host
The vulnerable server sends the request
The attacker observes the response, timing, or side effects
They use that behavior to map internal services, retrieve data, or pivot deeper

Common SSRF outcomes

The impact of SSRF depends on what the server can access and whether the attacker can see the response.

Internal network discovery

The attacker may probe internal IP ranges, ports, and services to learn what exists behind the perimeter.

Sensitive data exposure

If the application returns fetched content, the attacker may retrieve internal pages, service responses, or configuration data.

Cloud metadata access

In cloud environments, SSRF may be used to reach metadata services that expose instance details or temporary credentials if protections are weak. This is one of the reasons SSRF gets so much attention in cloud security.

Interaction with internal APIs

An attacker may send requests to back-end APIs that trust the application’s network location or service identity.

Security control bypass

A service that is restricted to internal callers may still be reachable if a public-facing app can be tricked into talking to it.

Not every SSRF flaw returns a visible response. In blind SSRF, the attacker may only infer success through:

Response timing
Error messages
DNS lookups
Outbound requests to infrastructure they control
Changes in application behavior

Blind SSRF can still be serious because it proves the server can reach destinations the attacker should not control.

Why SSRF matters in cloud environments

Cloud-hosted workloads often rely on metadata services for instance information, identity, and temporary access tokens. If an attacker can force a vulnerable application to query those services, the result may be:

Environment discovery
Credential exposure
Access to other cloud resources
Expanded post-compromise movement

In other words, SSRF is not just “the server fetched the wrong URL.” In cloud environments, it can become an identity and access problem.

When you will encounter SSRF

You are most likely to encounter SSRF in web application security, API security, and cloud architecture discussions.

During application testing

Developers, pentesters, and AppSec teams look for SSRF in features that accept URLs, remote file locations, callback endpoints, or import sources.

In bug bounty and pentest reports

SSRF is a common finding because modern applications often fetch remote content by design. Any user-controlled server-side request path is worth reviewing.

In cloud risk reviews

Security teams discuss SSRF when evaluating workloads that can reach metadata services, private APIs, or management endpoints from inside the environment.

During incident response

Responders may investigate unusual outbound requests from app servers, unexpected access to internal systems, or traffic to metadata-related addresses.

In architecture and design reviews

SSRF often starts as a design issue, not just a coding mistake. If an application must fetch remote content, teams should decide early what it is allowed to reach and what must always be blocked.

How to reduce SSRF risk

Reducing SSRF risk usually requires both application controls and network controls.

Restrict allowed destinations

Use allowlists for trusted domains, hosts, or services instead of letting users provide arbitrary destinations.

Block internal and sensitive addresses

Applications should reject requests to:

Localhost
Loopback ranges
Private IP ranges
Link-local addresses
Metadata service addresses
Internal admin interfaces

Normalize and validate input carefully

Attackers often use redirects, alternate encodings, DNS tricks, or unusual URL formats to bypass weak validation.

Limit outbound connectivity

Strong egress filtering reduces what the application can reach even if the code has a flaw.

Separate privileges and identities

Do not give every application broad network reach or unnecessary cloud permissions. Least privilege reduces the blast radius.

Harden endpoints and admin workflows

If a compromised system later leads to broader malware activity, endpoint protection can still help. Tools like Malwarebytes may be useful on business endpoints involved in web administration or testing workflows.

Protect credentials and secrets

Teams managing cloud and internal access should avoid password reuse and keep administrative credentials organized in a dedicated manager like 1Password to reduce secondary exposure if an application issue leads to broader investigation.

Bottom line

SSRF is a vulnerability that turns a trusted server into the attacker’s network proxy. If an application can be tricked into making arbitrary requests, the attacker may reach internal services, cloud metadata, or private APIs that were never meant to be exposed. That is what makes SSRF so dangerous: it abuses trust, placement, and connectivity rather than brute force.