The server becomes the attacker transport
Server-side request forgery occurs when untrusted input controls a request made by a server. The server can have network reachability, credentials, source identity, and protocol access that the external caller does not. The request can reach cloud metadata, control planes, loopback services, internal APIs, databases, file URLs, or another tenant.
An attacker may use the response directly, infer it through timing or status, or cause a state change without seeing the response.
Destination policy
Do not accept an arbitrary URL when the feature needs one known service. Store a server-side destination identifier and map it to an approved scheme, host, port, path prefix, and credential policy. If user-selected destinations are required, parse with one standards-compliant URL parser and validate each component after parsing.
Resolve the host and check every resulting address against the destination policy. Reject loopback, link-local, private, multicast, unspecified, and other special ranges unless the feature explicitly needs a named address in one of them. Recheck after DNS resolution and on each new connection. Protect against a name that changes address between checks.
Request and network controls
Allow only required protocols. Disable redirects or validate every redirect target with the same policy. Strip caller-supplied authorization, host, forwarding, and hop-by-hop fields. Attach a credential only after selecting the approved destination and bind it to that service.
Use egress policy as a second control. Put fetch workers in a network segment and identity context that cannot reach cloud metadata, control planes, or unrelated internal services. Bound response size, decompression, redirect count, connection count, and time.
Failure and residual risk
String checks can miss alternate numeric addresses, IPv6 forms, encoded delimiters, user information, fragments, and parser disagreement. DNS can return several addresses or change after validation. An allowlisted service can itself redirect or proxy. A blocked response body does not prevent blind state change or port discovery.
Pomerium boundary
Pomerium protects inbound routes that pass through it. SSRF originates from the protected server and often uses its outbound network position. Pomerium cannot constrain an arbitrary fetch performed inside the upstream unless that request is separately routed through an enforcement point. The application and network must apply destination, credential, egress, and resource policy.
Evaluation checklist
- Does the feature need arbitrary URLs, or can it use server-side destination identifiers?
- Are scheme, host, port, path, resolved addresses, redirects, and credentials validated together?
- Can the worker reach loopback, metadata, control planes, private services, or another tenant?
- Are user-supplied authorization and forwarding fields removed?
- Are response, decompression, time, connection, and redirect resources bounded?
- Do tests cover alternate address forms, DNS changes, redirect chains, blind effects, and credential forwarding?
