SSRF Meaning: What Server-Side Request Forgery Is and How to Stop It

SSRF stands for Server-Side Request Forgery, a web vulnerability in which an attacker manipulates a server into making HTTP requests to destinations the attacker chooses, including internal systems the attacker could never reach directly. The SSRF meaning matters because these flaws let an outside actor borrow your server's network position and trust, turning a feature that fetches a URL into a doorway to your internal infrastructure. This is a defensive explainer: how the class of bug works and, more importantly, how to shut it down.

Breaking down the acronym

• Server-Side because the request originates from your server, not the user's browser. That is the whole point: the server sits inside your network, behind your firewall, with access the attacker lacks.
• Request because the vulnerability is about the server making an outbound request, typically HTTP but sometimes other protocols.
• Forgery because the attacker forges or controls where that request goes, causing the server to act on their behalf.

Put together, SSRF is "I made your server send a request I designed, to a place I picked."

How SSRF happens

The vulnerable pattern appears any time an application takes a URL, or part of one, from user input and then fetches it server-side. Common legitimate features that introduce the risk:

• A "fetch preview of this link" feature.
• An image or document loader that pulls a resource from a user-supplied address.
• A webhook or callback URL the server calls.
• An integration that imports data from a URL the user provides.

Consider a preview endpoint that accepts a URL parameter and fetches it:

// Vulnerable: fetches whatever URL the user supplies
app.get('/preview', async (req, res) => {
  const url = req.query.url;
  const response = await fetch(url);
  res.send(await response.text());
});

Nothing validates where url points. An attacker supplies an address that resolves to an internal service, and the server dutifully fetches it and returns the response.

Why SSRF is dangerous

The danger is not that the server makes a request; it is where it can be steered.

Reaching internal services. Servers often sit on networks with internal databases, admin dashboards, and metadata services that are not exposed to the internet. SSRF lets an attacker reach those through the server, which is trusted on that network.

Cloud metadata exposure. In many cloud environments, instances can query an internal metadata endpoint that may return credentials and configuration. If SSRF lets an attacker hit that endpoint, they may harvest cloud credentials, which is one of the highest-impact outcomes.

Port scanning and mapping. By observing timing and error differences, an attacker can use SSRF to map internal services and open ports, learning the shape of a network they cannot otherwise see.

Bypassing access controls. Requests that come from the server may be trusted by internal systems that would reject external traffic, so SSRF can bypass network-based access controls.

SSRF has consistently ranked among the most serious web application risks precisely because a single fetch-a-URL feature can cascade into full internal compromise.

How to defend against SSRF

Defense is layered. No single control is sufficient, so combine several.

Validate against an allowlist. The strongest control. Instead of accepting arbitrary URLs, permit only a known set of allowed hosts or domains. Allowlists beat blocklists here, because blocklists are easy to evade with encoding tricks, redirects, and alternate address representations.

const ALLOWED_HOSTS = new Set(['images.example.com', 'cdn.example.com']);

function isAllowed(rawUrl) {
  try {
    const u = new URL(rawUrl);
    return u.protocol === 'https:' && ALLOWED_HOSTS.has(u.hostname);
  } catch {
    return false;
  }
}

Block requests to internal ranges. Reject URLs that resolve to private and reserved address ranges and to loopback. Do the check after DNS resolution, and re-check on every redirect, since a hostname can resolve to an internal address or redirect there after passing an initial check.

Restrict protocols. Allow only http and https. Deny schemes like file, gopher, and ftp that can be abused for more exotic attacks.

Do not follow redirects blindly. A URL that passes validation can redirect to an internal target. Either disable redirect following or re-validate each hop.

Segment the network. Limit what the server itself can reach. If the application server has no route to sensitive internal systems, a successful SSRF has far less to work with. Lock down cloud metadata access to the strictest version your provider offers.

Test for it. Include SSRF in your security testing. A DAST tool can probe URL-handling endpoints for this behavior against a running application, catching cases that slip past code review. Pair that with code review focused on every spot where user input flows into an outbound request.

For the underlying concept of the destination an attacker manipulates, see what is a target URL, which explains why user-controlled destinations need validation in the first place.

A safe design pattern

The reliable way to build a URL-fetching feature is to treat the user's input as untrusted from end to end:

1. Parse the URL and reject anything that is not a well-formed https address.
2. Check the hostname against an explicit allowlist.
3. Resolve DNS and reject private, loopback, and reserved addresses.
4. Fetch with redirects disabled, or validate every redirect hop with the same rules.
5. Constrain the response size and content type you will accept.

That sequence turns an open door into a narrow, controlled path.

FAQ

What does SSRF stand for?

SSRF stands for Server-Side Request Forgery. It is a vulnerability where an attacker causes a server to make HTTP requests to destinations the attacker controls, often to reach internal systems the attacker cannot access directly.

How is SSRF different from CSRF?

CSRF, Cross-Site Request Forgery, tricks a user's browser into making a request using the user's credentials. SSRF tricks the server into making a request from its own network position. Different actor, different trust being abused: CSRF exploits the user's session, SSRF exploits the server's access.

What is the most effective defense against SSRF?

Validating user-supplied URLs against an allowlist of permitted hosts and protocols is the strongest single control, combined with blocking requests to private and internal address ranges and not following redirects blindly. Network segmentation limits the damage if a bypass occurs.

Why is SSRF considered so dangerous in the cloud?

Cloud instances often expose an internal metadata endpoint that can return credentials and configuration. If SSRF lets an attacker reach that endpoint through your server, they may steal cloud credentials, which can lead to broad account compromise. That impact is why SSRF ranks among the top web risks.