An app fetches a user-supplied URL server-side (e.g., for link previews). What's the risk and fix?
Short answer
Server-side fetching of attacker-controlled URLs is server-side request forgery (SSRF): it lets an attacker reach internal-only services or the cloud metadata endpoint to steal credentials. Mitigate by allow-listing permitted hosts and schemes, blocking private and link-local ranges (re-checking after every redirect), and hardening metadata access with IMDSv2. Saying there's no risk ignores the access the fetch grants, and a loading spinner or response caching does nothing about where the server is allowed to connect.
When your server fetches a URL that a user controls — for a link preview, a webhook, an avatar import — it becomes a confused deputy. The attacker doesn't get to make the request, but they get to choose where your server makes it. That is server-side request forgery (SSRF), and on cloud infrastructure it is one of the most dangerous classes of bug.
Why this is the real risk
The server usually sits inside a trusted network with far more reach than any external client. By supplying a URL like http://169.254.169.254/latest/meta-data/, an attacker can pull the cloud metadata for the instance — including temporary IAM credentials — and pivot to your account. They can also hit internal admin panels, databases, and unauthenticated microservices that assume "if you can reach me, you're trusted." This is exactly how several major cloud breaches escalated from a single preview feature.
The correct fix
Defend in depth:
- Allow-list the exact hosts and schemes you intend to fetch (only
https, only known domains). An allow-list fails closed; a deny-list of "bad" ranges always misses something. - Resolve the hostname yourself and block private, loopback, and link-local ranges (
127.0.0.0/8,10/8,192.168/16,169.254/16, IPv6 equivalents) — and re-check after every redirect, because an allowed host can 302 you to169.254.169.254. - Harden metadata with IMDSv2, which requires a signed, session token via a PUT, defeating the simple GET an SSRF can perform.
Why the distractors are wrong
"No risk — it's just an HTTP fetch" is precisely the mindset that ships SSRF; the danger is the network position, not the protocol. A loading spinner is a UX detail. Caching the response may even worsen things by storing internal data. None of them constrain where the server connects, which is the whole problem the interviewer is probing.
Likely follow-ups
- How do you stop SSRF via DNS rebinding or an HTTP redirect to 169.254.169.254?
- Why is an allow-list of hosts safer than a deny-list of private ranges?
- What does IMDSv2 change about how the metadata endpoint can be reached?