Server-Side Request Forgery (SSRF) testing, proven
Server-Side Request Forgery (SSRF) (SSRF) — what it is, why a signature scanner misses the cases that matter, and how SuperPentest proves it with a controlled test, clean-session reproduction and hash-chained evidence mapped to A10: SSRF.
SSRF is a vulnerability class scanners only partly reach — here is what it is, why that is, and how SuperPentest proves it on your app.
What SSRF is
SSRF tricks a server into making requests on the attacker’s behalf — often to internal services or the cloud metadata endpoint, where it can retrieve credentials and pivot deeper into the infrastructure. In cloud environments SSRF is a frequent first step toward full account compromise.
What it looks like
An "import from URL" feature fetches whatever address you paste. Point it at http://169.254.169.254/latest/meta-data/iam/security-credentials/ and the server hands back its own cloud role credentials — the first step to taking over the account. Blind SSRF echoes nothing, so it is confirmed with an out-of-band callback to a server you control.
Why a scanner misses it
A scanner can flag a naive URL parameter, but blind SSRF with no response echoed back, and SSRF reachable only through an authenticated feature (webhook, PDF renderer, image proxy), need out-of-band interaction and reasoning about where the request actually lands — not a signature.
How SuperPentest proves it
SuperPentest treats SSRF the way an attacker does, in four steps: it understands the business rule the feature is meant to enforce, runs a controlled test against it, then reproduces any candidate from a clean session — a fresh login with no leftover state — and finally records the impact with hash-chained request/response evidence mapped to the control it breaks. Nothing is reported as a finding until that clean-session reproduction succeeds; a candidate is not a finding.
- Understand — map the feature and the rule it should enforce.
- Controlled test — exercise the class safely, within the authorized scope.
- Clean-session reproduction — break in again from a fresh session to rule out flukes and stale state.
- Impact + evidence — hash-chained request/response, mapped to A10: SSRF and your compliance controls.
Where it fits in coverage
Server-Side Request Forgery (SSRF) is one of the 35 vulnerability classes the engine tests every run, driven through 40+ specialist tools orchestrating 13 industry-standard open-source scanners. See the full coverage map or the 35 classes explained.
Related vulnerability classes
SQLi testing · XSS testing · IDOR testing · BOLA testing.
FAQ
Can a scanner find SSRF?
A scanner finds some cases, but misses the ones that matter — behind authentication, blind variants, or anything needing a multi-step workflow — and raises false positives on the rest. SuperPentest verifies each candidate before it counts.
How do I know a reported SSRF finding is real?
Every finding is reproduced from a clean session with hash-chained request/response evidence you can replay. If a run cannot complete the checks, it is stamped degraded coverage rather than passed as clean. See how findings are verified →
Test your app for SSRF. Book a demo or request an evaluation account. See the sample report.