Design Features That Fetch User-Supplied URLs

Security & Access · security, uploads, apis

Updated 2026-08-04

Recognize when a feature asks your server to visit an address a user typed. Import from a link, add an image by URL, set a webhook, and generate a preview all do this, and each one turns your infrastructure into the user's browser.
Understand what that permits. Your server sits inside your network, so a crafted address can point it at internal systems that were never meant to be reachable from outside, which is server-side request forgery.
Limit what the feature accepts rather than trying to catch what is dangerous. An explicit list of allowed hosts or shapes is the only approach that survives a determined attempt.
Apply the same caution to file paths and names. A supplied name that is used to build a path can reach outside the folder it was meant to stay in.
Design the refusal so it is usable. "We can only import from these sources" with the list beside it is a help, and a silent failure sends the user to support.
Never echo back what the server saw. A preview that renders an internal error page or a redirect target is exposing the thing the restriction was protecting.
Show what will happen before it happens. A preview step that says which address will be fetched, and when, keeps the user in control of a request made on their behalf.
Ask whether the feature needs to exist in this form at all. Uploading a file is often the same outcome with none of the exposure, and it is usually the simpler interface too.

Any field that accepts an address is a request your server will make, so it is a permission decision as much as an input decision.