---
title: "Find SSRF in HTTP Parameters"
canonical: https://trickest.com/library/ssrf-scanner
description: "Crawl a target and mine its archived URLs, then test every parameter that takes a URL for server-side request forgery using out-of-band detection."
---

# Find SSRF in HTTP Parameters

## Overview

Server-side request forgery is invisible from the outside. The response looks
normal whether or not the server made the request you asked it to, so the bug
sits in production until somebody thinks to test for it with a callback. That is
also why it survives code review: the parameter looks like a URL because it is
supposed to be one.

This finds the parameters that take a URL and tests each with out-of-band
detection, so a finding means the server actually reached out. You get the
reachable endpoints, the parameter that carried the payload, and the interaction
that proves it, which is the evidence a developer needs to accept the ticket.
Scheduling it makes it part of
[continuous security testing](/use-cases/continuous-security-testing) rather than
a one-off engagement.

## Pipeline

1. Read the target.
2. [katana](/tools/katana) crawls the live application and collects endpoints.
3. [gauplus](/tools/gauplus) adds URLs from public archives, including pages the
   crawl cannot reach.
4. Both sources merge into one candidate set.
5. [nuclei](/tools/nuclei) runs its DAST SSRF templates against every candidate
   with out-of-band interaction detection.
6. Confirmed interactions are written to a PDF report.

## Inputs

- **Target.** One application. It seeds both sources, the live crawl and the archive
  lookup, so you do not maintain a URL list alongside it.
- **Out-of-band detection.** [nuclei](/tools/nuclei) runs with interaction detection on,
  and that default is the point of the workflow. A finding is an interaction that
  arrived, not a response body that looked unusual.
- **Template set.** The DAST SSRF templates, not the whole [nuclei](/tools/nuclei)
  library. Keeping the set narrow is what stops a parameter test from turning into a
  general vulnerability scan you did not schedule time for.

## Outputs

- **A PDF report.** Confirmed interactions only, each with the endpoint, the parameter
  that carried the payload, and the interaction record that proves the server reached
  out. That is the evidence a developer needs to accept the ticket.
- **A merged endpoint set.** The union of the crawl and the archive, deduplicated, which
  is a reusable candidate list for any other parameter testing on the same target.
- **The crawl and archive sets on their own.** Each collector's output lands separately,
  so you can see which pages the crawl never reached.

## Sample output

The illustrative records below match the output shape and do not come from a
real run. They show how crawl and archive inputs become one test queue:

```jsonl
{"url": "https://example.com/fetch?url=https://internal", "param": "url", "source": "crawl"}
{"url": "https://example.com/proxy?target=127.0.0.1", "param": "target", "source": "crawl"}
{"url": "https://api.example.com/webhook?callback=https://attacker.example.com", "param": "callback", "source": "archive"}
{"url": "https://dev.example.com/import?src=http://169.254.169.254", "param": "src", "source": "archive"}
{"url": "https://example.com/preview?link=https://metadata.example.com", "param": "link", "source": "crawl"}
```

Detection is out-of-band, so the report lists the interaction that arrived rather
than a response body that looked unusual. That distinction is what makes these
findings straightforward to reproduce.

## FAQ

### Do I need to run my own callback server?

No. The out-of-band interaction detection built into [nuclei](/tools/nuclei) provides the
listener, and the interactions it records are what the report is built from. You do not
stand anything up.

### Why not just read the response?

Because the response is the same either way. A server that fetched your URL and one that
ignored it can return identical bodies, which is exactly why this bug survives code
review and why detection has to happen out of band.

### Is it safe to run against a third party?

Archive mining reads public data and touches nothing. The crawl and the payload delivery
are traffic to the target, and an SSRF payload asks their server to make a request on
your behalf, which is an action inside their network rather than a read of it. Run those
only with authorization.

### How is this different from running nuclei myself?

[nuclei](/tools/nuclei) needs URLs. Producing them is most of this workflow, crawling the
live application and recovering from archives the pages a crawl cannot reach, then
merging both into one candidate set. The template run is the last step.

### What does running it on a schedule buy?

New parameters. Every release adds endpoints, and a parameter that takes a destination is
the kind of thing that ships without anyone flagging it. Running after each deploy catches
it while the change is still fresh in someone's memory.

## Related workflows

- [Find Reflected XSS on a Domain](/library/xss-scanner). Reach for this instead when the parameter is
  reflected back to the user rather than fetched by the server.
- [Find Open Redirects on a Domain](/library/open-redirect-scanner). Reach for this instead when the
  server hands the URL to the browser rather than requesting it. Same parameter shape,
  different sink.
- [API IDOR and BOLA Scanner](/library/api-idor-and-bola-scanner-openapi). Reach for this
  instead when there is an OpenAPI spec, because enumerating it beats crawling for
  parameters.

---
_Markdown source of https://trickest.com/library/ssrf-scanner._