Server-side requests and redirects to a user-supplied URL
This check covers two related mistakes: your server fetching a URL that a user provided (server-side request forgery, or SSRF), and your app redirecting to a URL a user provided without checking where it points (open redirect).
#What goes wrong
A feature like 'import from URL' or 'fetch this webhook' takes whatever address the user types and passes it straight to fetch() on the server. A 'redirect back to where you came from' feature does the same with a return_to parameter and a redirect call.
#Why it matters
SSRF lets an attacker make your server request internal-only addresses, like cloud metadata endpoints that can leak credentials, or services behind your firewall the attacker couldn't otherwise reach. Open redirects are used in phishing, since a link through your trusted domain looks legitimate right up until it bounces somewhere else.
#How Heimdall checks for this
Heimdall looks for server-side fetch or redirect calls where the target URL comes from user input, a query parameter, or a request body, and checks whether that URL is validated against an allowlist before use.
#How to fix it
For server-side fetches, validate the URL against an allowlist of expected hosts before making the request, and block requests to private IP ranges and cloud metadata addresses. For redirects, only allow relative paths, or check the destination against a list of your own domains before redirecting.
Frequently asked questions
Is this only a risk if I let users submit arbitrary URLs?
What's a cloud metadata endpoint and why does it matter?
Is checking the URL string enough?
Run this check on your own repo
Heimdall scans your GitHub repo for this and 29 other issues in under a minute.