How would you prevent server-side request forgery when an API must fetch a URL supplied by a user?

Prevent SSRF when an API fetches user-controlled URLs

Secures webhooks, previews, imports, and remote-file fetches with destination policy, DNS and redirect defenses, egress controls, limits, and observability.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

The safest design avoids arbitrary destinations. When the business knows the integrations, I use an allowlist of exact schemes, hosts, and ports, parse with a trusted URI parser, resolve the destination, and reject loopback, link-local, private, multicast, and other forbidden ranges for both IPv4 and IPv6. I disable or revalidate redirects, permit only HTTP or HTTPS as required, and never copy inbound credentials to the outbound request. Time, response-size, and content-type limits prevent the fetch from becoming a resource attack.

Full answer below

Practice focus

SSRF, URL parsing, schemes, allowlists, DNS rebinding, redirects, private networks, metadata endpoints, egress controls, response limits, and audit telemetry.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Fetching a user URL turns the API into a network client with access the caller may not have. Simple string validation misses redirects, alternative address forms, DNS changes, and cloud metadata or internal services.
The safest design avoids arbitrary destinations. When the business knows the integrations, I use an allowlist of exact schemes, hosts, and ports, parse with a trusted URI parser, resolve the destination, and reject loopback, link-local, private, multicast, and other forbidden ranges for both IPv4 and IPv6. I disable or revalidate redirects, permit only HTTP or HTTPS as required, and never copy inbound credentials to the outbound request. Time, response-size, and content-type limits prevent the fetch from becoming a resource attack.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
For webhook or preview features that need broader internet access, validation and the connection must share a trustworthy destination policy. I validate every resolved address and each redirect target, account for DNS rebinding, and isolate the fetcher in a network segment that cannot reach internal services or cloud metadata. A fixed outbound proxy can centralize DNS, destination rules, logging, and rate limits. The result is streamed into a bounded buffer or object store rather than loaded without limit, and active content is not served back under a trusted origin without sanitization.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Blocking only URL strings that start with localhost or 127.0.0.1.
Validating the first URL but following redirects without another check.
Allowing every URI scheme accepted by a general parser.
Depending on application validation while the fetcher can reach internal networks.

How would you prevent server-side request forgery when an API must fetch a URL supplied by a user?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Tech stacks

Skill areas

Suggest an improvement