Outbound URL Requests and SSRF Boundaries

A server-side fetch has network reach and credentials that a browser visitor does not. If the visitor can choose its destination, the application may become a proxy to internal services, cloud metadata, or another tenant's resource. Treat an outbound URL as untrusted input: decide whether a fixed allowlist is possible, parse the complete URL, restrict schemes and ports, resolve and reject private or special addresses, enforce the rule after redirects and DNS changes, and cap response size and time. Network egress controls provide another boundary. The predicate below is only the first textual allowlist gate, not a complete SSRF defense; a fetch implementation must still enforce DNS and redirect checks at connection time.

Working case

A case editor accepts a URL for a reference photo and the server downloads it to create a thumbnail. An attacker submits a URL pointing at a private administration endpoint reachable only from the server. The response could be stored as an image or leak through error text. A safer design accepts direct file uploads or a small set of approved image hosts. If arbitrary URLs are a true product need, download through a dedicated service with constrained egress, byte and time limits, no ambient privileged headers, and a reviewed redirect policy.

Implementation boundary

function isApprovedImageLocation(candidateUrl) {
  try {
    const target = new URL(candidateUrl);
    const allowedHosts = new Set(["images.inspection.example", "media.inspection.example"]);
    return target.protocol === "https:" && allowedHosts.has(target.hostname)
      && (!target.port || target.port === "443") && !target.username && !target.password;
  } catch {
    return false;
  }
}

Cost and boundaries

DNS lookup, TLS negotiation, download transfer, decoding, and storage all consume resources before a thumbnail exists. A size limit must be enforced while streaming, because a claimed Content-Length may be absent or false. Redirect checks add work per hop, and a strict allowlist adds operational work when an approved provider changes hostnames. Those costs are preferable to granting general network reach to a request controlled by an untrusted user.

Failure trace

A filter checks only that the original URL begins with an approved hostname. The server follows a redirect into a private address and sends an internal authentication header along the way. Another attacker uses a hostname whose DNS answer changes between validation and connection. The initial textual check was never sufficient. Bind validation to the actual connection target, disable or revalidate redirects, strip ambient credentials, and restrict network egress so a parsing mistake is not the only defense.

Verification

Try a URL with user information, an alternate port, or a deceptive suffix; the textual gate must reject it.
Redirect from an approved host to a private destination and confirm the connector refuses the hop.
Stream a response beyond the byte budget and verify the download stops without storing a partial trusted asset.

Decision note

The safest fetch often is no fetch: accept a direct upload or an ID from a known provider. Add general outbound requests only when the product need justifies their ongoing security and operating cost.

Common Mistakes

Do not trust string-prefix URL checks.
Do not permit redirects or DNS resolution to bypass destination checks.
Do not forward server credentials to caller-chosen hosts.

Connected lessons

Identity and Application Security; Password Verification and Login Budgets; Account Recovery and Session Revocation; Federated Login Callback Boundary; Safe File Upload Pipeline; URLs and origins: separate location, query, and fragment; Environment Configuration and Secret Boundaries; Rate Limits and Request Budgets.

Apply and check

Build Project: account access and recovery boundary and review Web Development: identity and integration contracts quiz.

Further connections

Edge Request Normalization and Origin Trust.