SSRF Is a Cloud Identity Problem, Not Just a URL Filter

In brief: A server-side request forgery can turn an innocent fetch feature into access to internal services and cloud credentials. Durable defenses constrain destinations, redirects, DNS resolution, and workload identity together.

The vulnerable feature often looks harmless

Applications fetch remote content for link previews, webhooks, document imports, image processing, and security scans. The danger begins when an attacker controls any part of the destination and the server can reach networks that the attacker cannot. The application becomes a proxy carrying the server's trust into internal space.

Blocking a short list of strings is not enough. Alternate IP representations, IPv6 forms, redirects, user-info syntax, and DNS rebinding can transform an apparently public URL into a request for a loopback address, private service, or cloud metadata endpoint after validation has already passed.

Validate every network decision

• Allow only required schemes and ports, and reject credentials, fragments, ambiguous host syntax, and non-canonical address forms.
• Resolve the hostname, classify every returned address, and reject loopback, private, link-local, multicast, and reserved ranges for both IPv4 and IPv6.
• Revalidate every redirect target and pin the connection to the validated address so DNS cannot change between the check and the request.
• Apply response-size, content-type, timeout, and redirect limits so an allowed fetch cannot become a resource-exhaustion path.

Network controls must backstop application checks

Application validation will evolve and can regress, so the runtime needs an independent egress boundary. A dedicated fetch service with a narrow allowlist, isolated network path, and no access to production control planes dramatically reduces what a parser mistake can reach.

Cloud metadata protections also matter. Require session-oriented metadata protocols where supported, block metadata routes at the network layer, and give the fetching workload the smallest possible identity. If a request does reach an internal credential endpoint, there should be little or nothing useful to steal.

Test bypass classes, not one payload

A single request to a familiar metadata address is only a smoke test. A complete SSRF suite covers encoding tricks, decimal and hexadecimal addresses, mixed IPv6 notation, redirect chains, DNS changes, parser disagreements, and internal hostnames. It also verifies that failures do not leak response timing or body fragments.

KENSAI's proof-first approach records the destination classification and the actual connected address. That turns an apparent block into verifiable evidence that the request never crossed the intended network boundary.

Takeaway

Treat remote fetching as privileged network access. Validate and pin destinations, recheck redirects, restrict egress, and minimize workload identity so one parsing mistake cannot become a cloud compromise.