SSRF Testing (OWASP A10)

What SSRF looks like in a real application

A product lets users add an avatar by URL. The server fetches the image and stores it. Supplying the cloud provider's metadata address instead returns instance credentials, and those credentials frequently carry enough permission to read storage buckets. One convenience feature becomes infrastructure access.

SSRF earned its place on the list because cloud architectures made it far more valuable. The same flaw in a data centre reached an internal web server; in a cloud account it reaches an identity.

Where we look for SSRF

URL inputs — avatar and logo import, link previews, website verification, feed and sitemap import
Webhook configuration, which is SSRF by design and therefore needs egress control rather than input validation alone
Document and media processing: HTML to PDF converters, headless browsers and image libraries that follow embedded references
XML parsing, where external entity resolution produces SSRF as a side effect
File imports that resolve remote references, including spreadsheets and office documents
Integration configuration where an administrator supplies a host for an internal system
Redirect following, where an allowed host redirects to a blocked one and the server follows

The bypass techniques we test

Naive protections are common and rarely survive contact. We test alternate representations of loopback and link-local addresses, decimal and hexadecimal encodings, IPv6 forms and mapped addresses, DNS names that resolve to internal ranges, credential-embedded URLs that confuse host parsing, and time-of-check to time-of-use races where DNS resolves differently at validation and fetch.

Where the response is not returned to us, we detect blind SSRF through out-of-band interaction: a request arriving at our own infrastructure proves the fetch occurred even when nothing is echoed back, and timing differences map internal reachability.

What we assess beyond the vulnerability

The severity of SSRF depends almost entirely on what the network permits. We assess what the application's position actually reaches — metadata endpoints, internal services, databases, orchestration APIs — because that determines whether a finding is a curiosity or a critical path to your infrastructure.

How SSRF gets fixed

Prefer an allow-list of permitted destinations over any attempt to blacklist internal ranges
Resolve the hostname once, validate the resolved address, and connect to that address to close the DNS race
Do not follow redirects on user-supplied fetches, or re-validate the destination at every hop
Route outbound fetches through a dedicated egress proxy with its own network policy, so application code is not the only control
Require the metadata service's protected mode so a single header-less request cannot retrieve credentials
Scope instance roles narrowly, so credentials obtained through SSRF are worth as little as possible
Never return the raw fetched response to the user

Common questions

How serious is SSRF if the response is not shown to the user?

Often still serious. Blind SSRF allows internal port and service mapping through timing and error differences, can reach state-changing internal endpoints that need no response to be useful, and in cloud environments can retrieve credentials that are then exfiltrated through a different channel. We rate it on what the fetch can reach, not on whether output is echoed.

We block requests to internal IP ranges. Is that sufficient?

Usually not on its own. Blocklists are bypassed through alternate address encodings, DNS names resolving to internal addresses, redirects from permitted hosts, and resolution races between validation and connection. Allow-listing destinations and enforcing egress policy at the network layer is far more durable than filtering input.

Is SSRF relevant if we are fully cloud-hosted?

More relevant, not less. Cloud environments expose an unauthenticated metadata service that returns credentials, and internal service meshes are often reachable without further authentication. Cloud hosting is the main reason this category was promoted into the Top 10.

Do you test our webhook feature for SSRF?

Yes, though we treat it differently. A webhook is a deliberate outbound request to a user-supplied destination, so the vulnerability is not that the fetch happens but that it is unconstrained. We test what internal destinations it can reach, and the remediation is egress control at the network layer rather than input validation alone.

How do we let customers supply URLs safely?

Send the request from somewhere that cannot reach anything sensitive. Route user-supplied fetches through a dedicated egress proxy with its own network policy, resolve the hostname once and connect to the validated address, refuse redirects, strip credentials from the URL, and never return the raw response body to the requester.

Does SSRF matter if we run in a private network with no internet egress?

Often more, because the value of SSRF is reaching inward rather than outward. A private network typically contains internal services, orchestration APIs and databases that authenticate weakly or not at all on the assumption that only trusted systems can reach them. An application that can be made to issue arbitrary internal requests defeats that assumption.

What is the single most effective control against SSRF?

Network-layer egress restriction on the services that make outbound fetches. Input validation is bypassed regularly through encoding, DNS and redirect tricks, and it depends on every developer implementing it correctly on every feature. A network policy that simply cannot route to your metadata endpoint or internal ranges holds regardless of what the application code does.

Let's scope your infrastructure.

Tell us what you have built and what you are testing against. You will speak to a Lead Security Architect, not a sales desk, and you will get a written scope with a fixed price before any work begins.

Request a Technical Scope Direct line himanshu@wimd.in +91 88600 00832