Server-Side Request Forgery SSRF

Server-Side Request Forgery, also called SSRF, is a web security vulnerability where an attacker tricks the server into making a request to an unintended location.

In a normal flow, the server should request only trusted and expected resources. In an SSRF attack, user-controlled input can make the server call internal services, private networks, or unwanted external systems.

What It Is

SSRF happens when the application accepts a URL or request target from the user and the server uses it without proper validation.

Simple meaning:

Attacker gives a URL
        ↓
Server trusts that URL
        ↓
Server makes request to unintended location
        ↓
Sensitive internal data may be exposed

The dangerous part is that the request is made by the server, not directly by the attacker. So the attacker may reach systems that are normally not accessible from the public internet.

Why It Matters

SSRF is dangerous because servers often have access to internal systems that normal users cannot access.

An attacker may force the server to connect to:

internal-only services
private network resources
backend systems
cloud metadata endpoints
arbitrary external systems

Possible impact:

Risk	Meaning
Internal data leakage	Server may expose private service data
Credential leakage	Authorization credentials may be leaked
Internal service access	Attacker may reach systems hidden behind the server
Network misuse	Server can be used to call unwanted systems
Security bypass	Attacker uses server access instead of direct access

Core Flow

A typical SSRF flow looks like this:

Attacker sends malicious URL/input
        ↓
Application accepts the input
        ↓
Server makes request using that input
        ↓
Request reaches internal/private/unwanted system
        ↓
Sensitive data or internal response may leak

Example mental flow:

Hacker -> Public Web Server -> Private Network / Internal Services

Main Causes

The PDF highlights these important reasons for SSRF:

Cause	Meaning
Unvalidated user input	User-provided URL is used without proper checks
Lack of whitelisting	Application does not restrict allowed domains
Insufficient access control	Server can access too many internal resources
Unsafe parsing/processing	XML-like input may lead to XXE-style issues

Unvalidated User Input

Unvalidated user input is one of the main causes of SSRF.

Example risky flow:

User provides image URL
        ↓
Server fetches that URL
        ↓
URL points to internal/private resource
        ↓
Server unintentionally exposes internal data

A vulnerable pattern can look like this:

app.get("/user/image", async (req, res) => {
  const imageUrl = req.query.imgUrl;

  const response = await fetch(imageUrl);
  const data = await response.text();

  res.send(data);
});

Problem:

The server is trusting user-provided URL directly.

Safer idea:

function isValidUrl(url) {
  try {
    const parsedUrl = new URL(url);
    return parsedUrl.protocol === "https:";
  } catch {
    return false;
  }
}

app.get("/user/image", async (req, res) => {
  const userUrl = req.query.imgUrl;

  if (!isValidUrl(userUrl)) {
    return res.status(400).send("Invalid URL");
  }

  // Make request only after validation
});

Important rule:

Always validate user input before the server makes any request.

Lack of Whitelisting

Whitelisting means allowing only trusted domains or URLs.

Instead of allowing any user-provided URL, define a list of allowed domains.

Example:

const allowedDomains = ["api.example.com", "internal-service.local"];

function isAllowedDomain(url) {
  const parsedUrl = new URL(url);
  return allowedDomains.includes(parsedUrl.hostname);
}

Before making a request:

app.get("/fetch-data", async (req, res) => {
  const userUrl = req.query.url;

  if (!isAllowedDomain(userUrl)) {
    return res.status(403).send("Access to this domain is not allowed");
  }

  // Make request only if domain is allowed
});

Simple mental model:

Do not ask: Which URLs should I block?
Ask: Which URLs should I allow?

Whitelist validation reduces SSRF risk because the server cannot be forced to request random internal or external targets.

Insufficient Access Control

SSRF becomes more dangerous when the server has too much access.

The PDF mentions that we should create policies around what can be accessed from:

file system
operating system
database
network layer

This means the server should not be able to freely access everything.

Safer access control thinking:

Server should access only what it needs.
Nothing extra.

Example controls:

Layer	What to Control
File system	Restrict file access
Operating system	Limit process permissions
Database	Use minimum required DB permissions
Network layer	Restrict internal network access
External requests	Allow only approved domains

Simple flow:

Limit server permissions
        ↓
Limit network access
        ↓
Limit database access
        ↓
Limit file system access
        ↓
Reduce SSRF impact

Safe Request Libraries

The PDF mentions that popular libraries like node-fetch and axios can provide a first layer of protection against SSRF.

Example using node-fetch:

const fetch = require("node-fetch");

async function makeSafeRequest(url) {
  try {
    const response = await fetch(url);

    // Handle the response safely
    return response;
  } catch (error) {
    // Handle errors safely
    throw new Error("Request failed");
  }
}

Important:

Using a popular request library helps,
but it does not replace validation, whitelisting, and access control.

The safe approach is:

Validate URL
        ↓
Check whitelist
        ↓
Apply access control
        ↓
Use a reliable request library
        ↓
Handle errors safely

XML External Entity Attack XXE

XXE stands for XML External Entity attack.

It is a web security vulnerability where an attacker interferes with how the application processes XML data.

The PDF explains that XXE can allow an attacker to:

view files on the application server file system
interact with backend systems
interact with external systems that the application can access

Simple meaning:

Attacker sends XML input
        ↓
Application parser processes it unsafely
        ↓
Internal files or systems may be accessed

How XXE Relates to SSRF

XXE can become related to SSRF because XML processing may cause the server to access internal or external resources.

The PDF mentions that sometimes payload or user input is sent as XML, and the parser or serialization/deserialization logic may fail to distinguish between XML and normal input data.

This can lead to:

Unsafe XML execution
        ↓
Internal server data leakage

Also, file types like these can look XML-like:

HTML
SVG
PDF

So input parsing and file handling should be done carefully.

SSRF vs XXE

Topic	Meaning
SSRF	Attacker makes the server send requests to unintended locations
XXE	Attacker abuses XML processing to access files or internal/external systems
Common risk	Server may expose internal data or access internal systems

Simple comparison:

SSRF -> server makes unwanted request
XXE  -> unsafe XML processing may expose internal data

Basic Checklist

Use this checklist to reduce SSRF risk:

Do not trust user-provided URLs directly.
Validate all user input before making server-side requests.
Use whitelist validation for allowed domains.
Reject unknown or unapproved domains.
Apply access control on file system, OS, database, and network layer.
Restrict what the server can access internally.
Use reliable libraries like node-fetch or axios.
Treat request libraries as a first layer, not complete protection.
Handle request errors safely.
Be careful with XML parsing and XML-like payloads.
Validate uploaded or processed files like HTML, SVG, and PDF.
Avoid unsafe serialization/deserialization of user input.

Interview Style Answer

Server-Side Request Forgery, or SSRF, is a vulnerability where an attacker makes the server-side application send requests to an unintended location. This is dangerous because the server may have access to private networks, internal services, databases, or credentials that are not directly available to the attacker.

The main causes are unvalidated user input, lack of whitelisting, and insufficient access control. To prevent SSRF, we should validate all user-provided URLs, allow only trusted domains through whitelisting, restrict what the server can access at the file system, OS, database, and network levels, and use reliable request libraries like node-fetch or axios. We should also be careful with XML processing because XXE attacks can expose internal files or backend systems.

One-Line Summary

SSRF happens when an attacker tricks the server into making unwanted requests to internal or external systems.

Final Mental Model

User URL -> Server Request -> Internal Resource = SSRF Risk

Remember it like this:

Validate input
Whitelist domains
Restrict access
Use safe request libraries
Handle XML carefully

Or:

Do not let user input decide where your server should go.

What It Is​

Why It Matters​

Core Flow​

Main Causes​

Unvalidated User Input​

Lack of Whitelisting​

Insufficient Access Control​

Safe Request Libraries​

XML External Entity Attack XXE​

How XXE Relates to SSRF​

SSRF vs XXE​

Basic Checklist​

Interview Style Answer​

One-Line Summary​

Final Mental Model​