owlwarden

Fix server fetches a URL the caller controls in Hapi

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 Hapi CWE-918 / OWASP A10:2021

The vulnerable pattern in Hapi

HIGH likely Server fetches a URL the caller controls A10:2021 src/server.ts:91:28 89 │ const body = request.payload as { sourceUrl?: string } 90 │ // ssrf: the server fetches whatever host the caller names. 91 │ const upstream = await fetch(body.sourceUrl as string) │ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ destination chosen by the caller 92 │ return h.response(await upstream.json()) 93 │ },

This finding comes from the Hapi fixture in the owlwarden test suite. 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 handler; a schema alone checks the shape, not the destination.

const target = assertAllowedUrl((request.payload as { url: string }).url)
const upstream = await fetch(target, { redirect: 'error' })

If you are not using Hapi

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 Hapi checks

Rules with a tested Hapi example.

ssrf for every framework / All rules / owlwarden