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.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I use defense in depth because URL blocklists are easy to bypass. Application validation handles canonical scheme, host, port, credentials, redirects, and resolved A and AAAA addresses; network policy denies internal ranges and restricts egress even if validation fails. I consider split-horizon DNS, TOCTOU between validation and connection, IPv4-mapped IPv6, unusual numeric addresses, proxy behavior, and a public host that later resolves internally. Requests run under a dedicated identity with no ambient cloud or service credentials. Telemetry records tenant, normalized destination category, decision, duration, bytes, redirect count, and failure reason without logging secrets in URLs. Abuse throttles bound attempts per actor, and alerts cover blocked internal destinations and unusual egress. Tests include localhost, private ranges, metadata addresses, redirects to forbidden hosts, multiple DNS answers, oversized bodies, slow responses, and parser edge cases.

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.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

The server forwards its own authorization headers to the supplied host.
DNS is resolved during validation but the connection can use a different address unchecked.
Responses are buffered without byte or time limits.
The fetch worker has access to metadata endpoints and internal administration services.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

Why is a URL blocklist insufficient?
How do redirects and DNS rebinding affect the design?
What protections belong at the network layer?

Continue practice

No explicit flow link is set yet, so these are nearby drills from the same path or taxonomy.

Abstraction vs encapsulationConcept question / Easy / ~5 minContinue Access modifiersConcept question / Easy / ~5 minContinue ActionResult vs Typed ResultsComparison question / Medium / ~7 minContinue

Opening drill

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

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

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