# Request fuzzer

> Mark payload positions in a request, pick an attack mode and payload lists, and send a scope-locked, rate-capped run with status, length, time and diff columns.

Source: https://docs.subcloak.com/cloak-proxy/security/request-fuzzer/

Added in Cloak Proxy 0.5.1.

Take a request, mark the parts you want to vary with `§` markers, give each position a list of payloads, and Cloak Proxy sends every combination and lays the responses out in a grid: status, length, time, whether each response differs from the original, and which of your grep terms it matched. Every run is locked to the hosts in your [scope](https://docs.subcloak.com/cloak-proxy/security/scope/) and asks you to confirm it first.

Use it to check your own API: find the id that returns someone else's record, the parameter that isn't validated, the endpoint that 500s on an empty value, the hidden field a form accepts.

*[Screenshot: The Request fuzzer window: on the left a GET request with id=§1§ marked, Auto-Mark, Clear Marks and Insert §§ buttons, the Sniper, Battering ram, Pitchfork and Cluster bomb modes, a Numbers payload from 1 to 50, a grep term error, and the active scope ShopApp API test with Manage scope…; in the middle a results table with the baseline and seven rows with payload, status, length, time, diff and grep columns, including a 500 and a 200 whose payload was reflected; on the right the selected result's response and the request that was sent.. Mark positions on the left, read the response grid on the right. A row that differs from the baseline, or matches a grep term, stands out.]*

> **Only fuzz systems you're allowed to test:**
> The fuzzer sends real requests to the real server. It only reaches hosts in your scope, and it asks you to confirm the count and the target before it starts — but it is still your responsibility to run it only against an API you own or have written permission to test. Keep the rate and concurrency gentle.

## Open it

1. Start from a request:

   | Where | Starts from |
   |---|---|
   | Right-click a request in the traffic list → **Send to Fuzzer…** | That captured request |
   | In the API Client, right-click a saved request → **Send to Fuzzer…** | That request |
   | **Tools › Request Fuzzer…** | A blank request (or the selected one) |

2. Mark the positions you want to fuzz. Wrap a value in `§` markers — `id=§1§` — by selecting it and typing `§`, or press **Auto-Mark** to mark every query and form value, or **Insert §§** to add an empty insertion point. **Clear Marks** removes them all. To send a literal `§`, write `\§`.

3. Choose an **attack mode** and add a **payload** list for each position (see below).

4. Add the target host to your [scope](https://docs.subcloak.com/cloak-proxy/security/scope/#tools-that-send-requests) (local servers are not special — add `localhost` too), then press **Run** and confirm. The window shows the active scope, with **Manage scope…**; without an active scope, a run doesn't start.

## Attack modes

**Sniper**
One position at a time, one payload list. Each payload is tried in each position in turn while the others keep their original value. For walking a single list across several spots.</Card>
**Battering ram**
The same payload in every marked position at once, one payload list. For when a value repeats (an id in the path and the body).</Card>
**Pitchfork**
One list per position, stepped together: position 1 takes list 1's first item, position 2 takes list 2's first, then the second of each, and so on. For paired data, like a username and its matching token.</Card>
**Cluster bomb**
One list per position, every combination. For trying each username against each password. The count is the product of the lists, so it grows fast — the request cap guards you.</Card>

## Payloads and processing

Each position's payloads come from one of:

- **List** — type them, one per line.
- **Numbers** — a range (`from`, `to`, `step`), optionally hex or zero-padded.
- **File** — one payload per line, read from a wordlist file you pick.
- **Wordlist** — one of the small sets Cloak Proxy ships: common parameter names, HTTP methods, boolean-ish values, common paths, edge numbers and boundary strings. These are for discovery and input-validation testing; Cloak Proxy doesn't ship attack dictionaries (SQL injection, XSS) — load those from a file when you need them.

Each payload can be **processed** before it goes in: add a **prefix** or **suffix**, and **encode** it (URL, Base64, hex, HTML entities, upper/lower). The prefix and suffix are added first, then the whole thing is encoded.

## Reading the results

One row per request, plus the **baseline** (the unmodified request) at the top to compare against.

| Column | What it shows |
|---|---|
| **Payload** | The payload(s) used in this request |
| **Status** | The response status code |
| **Length** | Response body size in bytes |
| **Time** | How long the request took |
| **Diff** | A dot when the response differs from the baseline (status or length), and an arrow when a payload was reflected back in the body |
| **Grep** | Which of your grep terms matched this response |

Select a row to see its full request and response. Tick **Compare to baseline** to see the two responses side by side, with changed, added and removed lines highlighted.

Right-click a row to **Send to API Client** (to keep working on that exact request), **Send to Authorization Matrix…** (to test it as [other users](https://docs.subcloak.com/cloak-proxy/testing/authorization-matrix/)), or **Add to Findings…**, which adds the result to an engagement's [findings](https://docs.subcloak.com/cloak-proxy/security/findings/). **Export Results as CSV…** is in the toolbar menu.

## Scope and safety

- A run only reaches hosts in your scope. The target's host is checked before the run starts, and again for every request — so a payload can't redirect traffic to a host you didn't allow.
- Every run asks you to confirm the request count and the target first. Nothing runs unattended.
- The **rate** (requests per second) and **concurrency** default to gentle values; a **max requests** cap stops a wide cluster bomb before it starts. Press **Stop** to cancel at once.
- By default requests go straight to the server. Turn on **Send through Cloak Proxy** to record them in the traffic list and apply your rules and breakpoints.

## From the command line

For CI and scripted testing, `cloakctl fuzz` runs the same engine:

```bash
cloakctl fuzz --request order.txt --mode sniper \
  --numbers 1:1000 --scope api.example.com \
  --grep "forbidden" --rate 20 --confirm
```

`order.txt` is the request with `§` positions. Without `--confirm` the command is a dry run that prints the count and a sample and sends nothing. `--scope` is required; local servers are not special. Pass `--fail-on-match` to exit non-zero when a grep term matches, for a CI gate. Run `cloakctl fuzz` with no arguments for the full option list.

An assistant can plan a run with the read-only **`fuzz_preview`** MCP tool, which reports the request count, the scope verdict and a sample — but it sends nothing. Running a fuzz stays with you, in the app or with `cloakctl fuzz --confirm`.

> **On Linux:**
> (added in Cloak Proxy 0.5.1) There's no Request Fuzzer window in the Linux app yet. Use `cloakctl fuzz`, and `fuzz_preview` from an assistant.

## Related

  - [Scope](https://docs.subcloak.com/cloak-proxy/security/scope/): The hosts the fuzzer is allowed to reach.
  - [Authorization Matrix](https://docs.subcloak.com/cloak-proxy/testing/authorization-matrix/): Replay a fuzzed request as other users.
  - [Findings and reports](https://docs.subcloak.com/cloak-proxy/security/findings/): Record a result with its request and response as evidence.
  - [cloakctl](https://docs.subcloak.com/cloak-proxy/automation/cloakctl/): Run the fuzzer from a script with cloakctl fuzz.