Server Fetches a URL Supplied by the Request

Why it matters

Your server sits inside your network and next to your cloud metadata service, database and internal admin tools. A fetch to an address chosen by the caller can reach those places on the caller's behalf. Limiting the destination to hosts you expect keeps the feature and removes the exposure.

What it looks like

This is the shape of code that triggers the rule. AI tools produce it because it works, and nothing tells them it is unsafe.

const express = require('express');
const app = express();
app.post('/preview', async (req, res) => {
  const r = await fetch(req.body.url);
  res.send(await r.text());
});

The smallest fix

const target = new URL(req.body.url);
const ALLOWED_HOSTS = ['api.github.com', 'images.example.com'];
if (!['http:', 'https:'].includes(target.protocol) || !ALLOWED_HOSTS.includes(target.hostname)) {
  return res.status(400).json({ error: 'That address is not allowed' });
}
const upstream = await fetch(target.toString(), { redirect: 'manual' });

The better fix

If you have a few more minutes, this is the approach that holds up as the app grows.

// For open-ended features (link previews), resolve the hostname first
// and reject private and loopback ranges, disable redirects, and put a
// short timeout and a size limit on the response. Libraries such as
// "ssrf-req-filter" or "private-ip" do the range check for you.

Let your AI tool fix it

When the scanner finds this in your project, it fills in the file and line for you. This is the prompt it gives you to paste into Claude Code, Cursor or whatever you use.

How to check the fix worked

1. Send a request with url=http://127.0.0.1:3000/ and confirm a 400.
2. Send url=http://169.254.169.254/ and confirm a 400.
3. Send an allowed URL and confirm the feature still works.

Further reading

• https://cwe.mitre.org/data/definitions/918.html
• https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html