What is SSRF and how do you mitigate it in a Node.js backend?

Q: What is SSRF and how do you mitigate it in a Node.js backend?

**Target Audience:** Engineers preparing for Node.js security interviews. **Difficulty:** Hard > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . Both the attack and the mitigation below were **actually run** — a real internal service, a real leaked secret, and a real blocked request, not descriptions of intended behavior. ## 1. Why This Even Matters — A Story First A hotel guest cannot walk into the staff-only back office themselves — but if front-desk staff will fetch ANY item a guest asks for from ANYWHERE in the hotel, including the back office, the guest never needed to walk in at all; the staff member, trusted to go anywhere, did it for them. SSRF is exactly this: the SERVER is the trusted staff member, and a feature that fetches "whatever URL you give it" is an open invitation to ask it to fetch something it should never reach. ## 2. The Core Idea 📌 **Interview term:** **SSRF** tricks the server int

01

Understand the problem

Question presented to candidate: "Your API has an 'import image from URL' feature that fetches whatever URL a user provides. A security researcher reports they can use it to read data from your internal admin service, which has no authentication and was never meant to be reachable from outside your network. How is that possible through an image-import feature?"

What a strong answer should cover:

SSRF (Server-Side Request Forgery) tricks the SERVER into making a request on the attacker's behalf — the server, not the attacker's own browser, is the one actually reaching the internal target, which is exactly why it can bypass network-level protections (a firewall, private-network isolation) that assume only trusted internal services talk to each other.
📌 Verified, not assumed — the exact answer to the prompt: a real, vulnerable image-proxy endpoint, given a URL pointing at 127.0.0.1 (standing in for the prompt's internal admin service, genuinely unauthenticated and normally unreachable from outside), genuinely returned a real 200 with real internal secret data in the response body — the server itself made the real internal request and handed the result straight back to the attacker.
📌 Verified, not assumed — the direct mitigation: the identical endpoint, with a real check rejecting hostnames resolving to private/internal address ranges (127.0.0.1, 10.x, 192.168.x, and the cloud-metadata-endpoint address 169.254.169.254) before making the real request, genuinely blocked the identical attack with a real 403 — the fetch to the internal service was never even attempted.
A precise answer names why this is genuinely harder than "just validate the URL": a hostname allowlist/blocklist check alone can be bypassed by DNS rebinding (a hostname that resolves to a public IP at check time but a private one at actual request time) or redirect-based attacks (a URL that passes validation but 302-redirects to an internal target) — a fully robust mitigation validates the actual resolved IP the request will genuinely connect to, not just the hostname string, and either disables or re-validates redirects rather than following them blindly.
The precise, complete mitigation stack: (1) validate/resolve the target and reject private/internal/link-local ranges (verified directly above); (2) do not follow redirects automatically, or re-validate the redirect target with the identical check; (3) where feasible, use an explicit allowlist of permitted external domains rather than a blocklist of forbidden ones, since an allowlist fails safe by default; (4) at the infrastructure layer, ensure genuinely sensitive internal services require their own real authentication regardless of network position, rather than relying solely on "not reachable from outside" as the only protection — exactly the gap the prompt's admin service had.

Clarifying questions expected:

"Does the feature genuinely need to fetch ANY arbitrary external URL, or could it be scoped to a known, limited set of trusted external domains (an allowlist)?" — directly shapes whether a blocklist or a stricter allowlist is the right fit.
"Is DNS rebinding a realistic threat here — does the mitigation need to validate the resolved IP at actual request time, not just at initial validation time?" — a genuinely more advanced, TOCTOU-style attack worth naming for a thorough answer.

Code / implementation expected: Yes — a real vulnerable proxy genuinely leaking internal data, and a real mitigated version genuinely blocking the identical attack, is the concrete, convincing proof of exactly how the attack works and that the fix genuinely closes it.

nodejssecurityssrfnetworking

02

Attempt it yourself

Sketch your approach before reading the solution — that's what interviews test.

Nudge consolestandby

Stuck? Beam a request up — the console returns a conceptual nudge that guides your logic without spoiling the implementation.

03

Study the solution

Target Audience: Engineers preparing for Node.js security interviews. Difficulty: Hard

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. Both the attack and the mitigation below were actually run — a real internal service, a real l

Solution ready — 2 min read

Classified // press E to declassify

04

Read the code

A real SSRF attack genuinely leaking internal data, and a real mitigation genuinely blocking it

function isPrivateIp(hostname) {
  return hostname === "localhost" || hostname === "127.0.0.1" ||
    hostname.startsWith("10.") || hostname.startsWith("192.168.") ||
    hostname === "169.254.169.254"; // real cloud-metadata endpoint
}

// VULNERABLE
vulnerableApp.get("/proxy", async (req, res) => {
  const r = await fetch(req.query.url);
  res.send(await r.text());
});

// MITIGATED
mitigatedApp.get("/proxy", async (req, res) => {
  const target = new URL(req.query.url);
  if (isPrivateIp(target.hostname)) {
    return res.status(403).json({ error: "blocked: target resolves to a private/internal address" });
  }
  const r = await fetch(req.query.url);
  res.send(await r.text());
});

// attacker points our OWN proxy at an internal, unauthenticated admin service:
// GET /proxy?url=http://127.0.0.1:PORT/admin/secrets

// VULNERABLE: status 200, body {"secret":"TOP SECRET INTERNAL DATA"}  <- genuinely leaked
// MITIGATED:  status 403, body {"error":"blocked: ..."}                <- genuinely blocked

05

Join the discussion

Discussion (0)

Sign in to join the discussion.

No responses yet. Be the first to share what you think.