Pricing Contact Case Studies Research Talk to a Pentester ↗
POCFORGE RESEARCH 5 MIN READ Threat intel

SSRF in web applications: how it is found, what it leads to, and how to prevent it

Server-side request forgery turns an application's own "fetch this URL" features into a route past the firewall. This is what it is, where it appears, what it leads to, and the controls that stop it.

Illustration: a glowing server sends an orange beam of light past a cyan dome that encloses a cluster of internal servers, representing a server-side request crossing a trust boundary.
In SSRF the server, not the user, makes the request, from inside the trust boundary.

SSRF turns an application’s own “fetch this URL” feature into a way to make the server reach places an attacker never could. These are our working notes: what it is, where we find it, and what it buys. No working payloads.

Weakness
CWE-918
Server-side request forgery
OWASP Top 10
A10:2021
Added on community survey
Who sends it
The server
From inside the network
Top prize
Cloud creds
Via metadata service

What it is, in one line

MITRE: a server “retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.” We are not attacking the app — we are borrowing its position on the network.
Illustration: a laptop sends an orange beam to a central server; the server sends a cyan beam out to a distant cloud and an orange beam through a translucent cyan wall into a walled zone of internal servers.
The user's request becomes the server's request. One path goes where intended; the other crosses the trust boundary.

Where we go looking first

Link previews
“Unfurling” of pasted links
Webhooks
Callback & notification URLs
Generators
PDF / report / screenshot tools
Import “from URL”
Image, document or data import
Integrations
User-typed server addresses
Parsers (XXE)
XML external entities become SSRF

None of these announce themselves as risky, so we enumerate them methodically. OWASP also notes the server-side request can use schemes beyond plain HTTP.

What a confirmed SSRF buys

01 · Proxy
Reach what we can’t
The app makes requests for us. CWE-918 calls it “bypass protection mechanism” — the request looks trusted, so it slips past firewalls.
02 · Credentials
Cloud metadata
OWASP: SSRF is often used to steal tokens from metadata services. AWS serves IAM role credentials on a link-local address only the instance can reach.
03 · Pivot
Map & move
Map internal networks, expose data, abuse internal services. A proven SSRF is a starting position, not the finish.

We grade severity by what comes back. Blind SSRF (only a yes/no) is reported differently from one that returns the full internal response — which is why raw responses should never reach the client.

The request flow

Step through three views of the same feature: intended use, an abused request, and the same request against a protected design. Hover or tap each component to see its role.

Illustration: a glowing hexagonal shield gate in a stream of light pulses; cyan pulses pass through an open slot while orange pulses are stopped and scatter as sparks against the shield.
An allowlist is a gate: approved destinations pass, everything else stops before the server makes a request.

How we test it in an engagement

1
Enumerate every fetch feature
Including admin-only settings and server-side file parsing. One missed field is usually the one that matters.
2
Confirm the primitive
Point it at an endpoint we control; watch whether the server calls out, and from what source address.
3
Test the controls
Allowlist enforcement, schemes and ports, and whether a redirect to a disallowed destination is refused or followed.
4
Test resolution
Does the control apply to the address actually connected to? DNS rebinding and time-of-check gaps live here.
5
Measure leakage & cloud exposure
What responses, errors or timing reveal; verify egress rules and IMDSv2 enforcement independently.

All within an agreed scope, against test endpoints we control — the aim is to prove behaviour, not cause impact. We pair this with code review (OWASP points to Semgrep rules) where we have access.

What stops it

Diagram: before controls, an app server reaches an allowlisted site, another public site, an internal service and cloud metadata; after controls, a gate refuses all but the allowlisted site.
Before and after controls. Conceptual illustration; destinations are generic.
Allowlist, don’t denylist. Match the host to an explicit list and build the request yourself.
Lock schemes & ports. HTTPS (or HTTP) only, on expected ports.
Don’t follow redirects. So an allowed host can’t hand off to a blocked one.
Pin the resolved IP. Connect only to validated addresses; beware a second DNS lookup.
Don’t return raw responses. Only the fields the feature needs; generic errors.
Segment egress. Own network zone, deny-by-default outbound rules.
Require IMDSv2. Disable IMDSv1; keep instance roles least-privilege.
Block link-local. If a denylist is unavoidable, block 169.254.169.254, loopback, private ranges and IPv6 equivalents.
Illustration: separate network zones of servers on a dark grid, each fenced by thin cyan light walls, with a single narrow orange exit channel leading out of one zone.
Segmentation and deny-by-default egress: the fetching component sits in its own zone with one controlled way out.
Want this tested on your own app?

PoCForge runs authorised web application and attack-surface assessments. For SSRF, we find every feature that fetches on a user’s behalf, test them the way a real adversary would within an agreed scope, check that allowlists, redirects, egress and metadata protections hold up together, and report clear, prioritised fixes your developers can act on.

Sources