SSRF from a user-supplied URL — how to fix it

If your server fetches a URL that the user provides, an attacker can point it at your internal network or your cloud provider's metadata endpoint instead of an external site. That turns your server into a proxy for reaching things it should never expose. The fix is to validate the destination against an allowlist and block internal addresses.

Why it's a problem

Your server usually sits inside a trusted network, so a request it makes can reach internal services, admin panels, and the cloud metadata endpoint that hands out credentials. An attacker who controls the URL you fetch can read those responses or trigger internal actions, which is why SSRF is often a path to full compromise.

// fetches whatever URL the user sends
app.post("/preview", async (req, res) => {
  const r = await fetch(req.body.url);
  res.send(await r.text());
});

const ALLOWED_HOSTS = new Set(["images.example.com"]);

app.post("/preview", async (req, res) => {
  const url = new URL(req.body.url);
  // only https, only approved hosts, never internal addresses
  if (url.protocol !== "https:" || !ALLOWED_HOSTS.has(url.hostname)) {
    return res.sendStatus(400);
  }
  const r = await fetch(url);
  res.send(await r.text());
});

Why AI tools write this

Fetching a user-provided URL is the direct implementation of features like link previews, webhooks, and image imports, so it is a natural completion. It works against public URLs in testing, and the internal-network reach only becomes a weapon when an attacker supplies an internal address.

The quick fix

• Validate the URL against an allowlist of hosts you trust.
• Allow only https and block requests to private and link-local IP ranges and the cloud metadata endpoint.
• Do not follow redirects to unapproved hosts.