Features that fetch a URL a user provides, generating a link preview, testing a webhook, importing content from a page, are common and genuinely useful. They also open a specific category of vulnerability worth its own careful teardown: server-side request forgery, usually shortened to SSRF.
What this vulnerability actually is
When your server fetches a URL on a user's behalf, that request is being made from your server, not from the user's own browser. Your server often sits somewhere with network access a regular visitor's browser doesn't have: internal admin tools, cloud infrastructure metadata services, databases reachable only from inside your own network. If your URL-fetching feature doesn't restrict what addresses it's willing to reach, a user can supply an internal address instead of a normal public one, and your own server will dutifully make that request for them, from a position of trust the outside internet was never supposed to have.
A concrete way this gets exploited
Cloud hosting providers commonly expose an internal metadata service at a specific, well-known internal address, used by the server itself to fetch its own configuration details, sometimes including credentials. A URL-fetching feature with no restrictions can be pointed at that exact internal address instead of a real external website. Your server, doing exactly what the feature asks, requests that internal address and hands back whatever it returns, potentially including sensitive configuration data that was never meant to be reachable from outside the server itself, let alone from a random user's input field.
Why this is a genuinely serious category despite being niche-sounding
This is precisely the kind of check a security scanner specifically designed for AI-built apps looks for, because it's exactly the sort of thing that's easy to build without thinking about, and genuinely serious when it's present: your own server becoming an unwitting proxy into places it has trusted access to, purely because a feature asked it to fetch a URL without checking where that URL actually pointed.
How to actually check your own app
- Find any feature that fetches a URL supplied by a user: link previews, webhook testers, import-from-URL features, anything similar.
- Try supplying an internal-looking address, a local network address, instead of a normal external URL, and see whether your server actually attempts to fetch it.
- If it does, and especially if it returns any actual content back to you, that's the vulnerability, confirmed directly.
The fix
Any feature that fetches user-supplied URLs needs to explicitly block requests to internal, private, or otherwise restricted address ranges, resolving the actual destination and checking it before making the request, not just checking the text of the URL, since a hostname can resolve to an internal address in ways that aren't obvious from reading the URL alone. This is exactly the kind of check that's easy to skip when building a link-preview feature quickly, and exactly the kind of gap that turns a small convenience feature into a path toward your own internal systems.
If your app fetches URLs on behalf of users anywhere at all, this is worth testing specifically, since it's a different failure mode from nearly everything else on this blog, less about who can see your data directly and more about what your own server can be tricked into reaching on someone else's behalf.