Short answer: Do not let a public image URL fetch arbitrary user-supplied destinations. Prefer registered source identifiers, restrict schemes and hosts, resolve and validate addresses, recheck redirects, block private networks, isolate egress, and enforce strict response limits.
An origin-pull image service makes server-side requests on behalf of a caller. Without controls, an attacker may target internal services, cloud metadata endpoints, localhost, administrative interfaces, or large responses. Image decoding does not make the request safe.
Prefer source IDs over arbitrary URLs
The safest public interface accepts an approved asset ID or a path relative to a configured origin. The service looks up the actual base URL and credentials from trusted configuration. Callers cannot choose the scheme, host, port, or network destination.
If a business workflow must import remote URLs, place it behind authentication and an ingestion job. Fetch once, validate, store the result as a managed asset, and serve future derivatives from that controlled source. The upload pipeline describes the validation stages.
Avoid embedding remote credentials in public URLs. Configure origin authentication on the server and scope it to a narrow path.
What should a URL allowlist validate?
Allow only required schemes, normally HTTPS. Parse with a maintained URL library and reject ambiguous or malformed forms. Compare normalized hostnames against an exact allowlist or a carefully defined subdomain rule. Do not use a substring check.
Disallow unexpected ports, user-info fields, IP literals, and fragments. Normalize internationalized domains consistently. Resolve DNS and reject loopback, link-local, private, multicast, and other nonpublic address ranges unless a specifically isolated private origin is part of the design.
OWASP’s SSRF Prevention Cheat Sheet details allowlisting, network controls, and common bypasses. Apply the checks before each connection, not only when configuration is saved.
Why must redirects and DNS be rechecked?
An allowed public URL can redirect to a forbidden internal destination. Either disable redirects or validate every hop with the same policy. Limit the number of hops and do not forward origin credentials across hosts.
DNS answers can change between validation and connection. Resolve through a controlled resolver, validate all returned addresses, and ensure the connection uses an approved result. Rebinding defenses need both application validation and network egress controls.
Cloudflare documents its source-origin allowlist for image transformations. Product protections vary, so do not assume a managed fetcher exactly matches your allowlist requirements.
What network controls provide defense in depth?
Run fetch and decode work in an isolated environment with no route to internal control planes or metadata services. Use outbound firewall rules or a proxy that permits only approved destinations. Separate this worker’s identity from application and infrastructure credentials.
Network controls remain valuable if URL parsing has a bug. Application allowlists remain valuable if network configuration changes. Neither layer should be the only barrier.
Set connection, header, body, and total timeouts. Limit response bytes before buffering, verify the detected media type, cap decompressed pixels and frames, and abort slow streams. A valid public host can still return a decompression bomb or an endless response.
How do signatures help?
A signature can ensure that only a trusted application constructs a remote-fetch request. It does not make the destination safe by itself. The signer must enforce the allowlist and resource policy before issuing the URL, and the image service should still enforce its own limits.
Use the signed URL policy to cover the approved source reference and transformation. Do not sign a base URL while leaving a redirect target or nested source parameter mutable.
What should be logged and alerted?
Log the normalized source ID, approved host, resolved public address, redirect count, response size, content type, timing, and rejection reason. Avoid logging embedded credentials, full signed tokens, or sensitive query strings.
Alert on denied private addresses, repeated malformed hosts, unusual ports, redirect loops, high fetch failure rates, and sudden traffic to a new approved origin. Correlate source fetch logs with transformation requests through a safe request ID.
The image pipeline observability guide describes broader operational signals. SSRF defenses should appear in the same dashboards and incident playbooks as reliability failures because attackers often look like unusual origin errors first.
Remote fetching is a privileged server capability. Expose a controlled asset vocabulary to normal callers, isolate the component that performs network access, and make every rejected destination visible enough to investigate.
Leave a Reply