Fix server fetches a URL the caller controls in Gatsby

An outbound HTTP request is made to a URL that came from the caller. The server can reach hosts the caller cannot - cloud metadata endpoints, internal admin services, databases bound to localhost - so this turns the server into a proxy into its own network. Validate the destination against an allowlist before fetching it.

high likely Gatsby CWE-918 / OWASP A10:2021

The vulnerable pattern in Gatsby

HIGH likely Server fetches a URL the caller controls A10:2021 src/api/proxy.ts:16:28 14 │ // ssrf 15 │ if (target) { 16 │ const upstream = await fetch(target) │ ~~~~~~~~~~~~~ destination chosen by the caller 17 │ return res.json(await upstream.json()) 18 │ }

This finding comes from the Gatsby fixture in the owlwarden test suite, in /api/proxy. The destination of this request comes from the caller, so they choose which host the server connects to. That includes hosts they cannot reach themselves: the cloud metadata endpoint that hands out IAM credentials, internal services that skip authentication because they are 'not exposed', and anything bound to localhost.

The corrected handler

Validate in the Function handler before fetching, and refuse redirects.

const target = assertAllowedUrl(req.body.url)
const upstream = await fetch(target, { redirect: 'error' })

If you are not using Gatsby

Check the destination against an allowlist of hosts before fetching it. Blocklists do not work here: DNS rebinding, redirects, and IPv6-mapped addresses all defeat them.

Check your own repository

npx owlwarden scan
npx owlwarden explain ssrf

Runs on your machine. No account, no telemetry, no network unless you ask. In CI, SARIF uploads to code scanning and the exit code is the gate.

Other Gatsby checks

Rules with a tested Gatsby example.

ssrf for every framework / All rules / owlwarden