The Scanner — passive to active proof

01The mental model — replay, not crawl

Most scanners start by spidering a target: they fetch a seed URL, parse it, follow links, and fuzz whatever they find. Crusader's scanner does none of that. It works entirely over already-captured History — the requests and responses that flowed through the proxy while you browsed, drove the app, ran the mobile sandbox, or replayed in Repeater.

That design has a direct consequence for how you use it: you have to capture traffic first. Point your browser or app through the proxy, exercise the surface you care about — log in, click through the authenticated flows, hit the API — and only then run the scan. An empty History yields an empty scan. The upside is that the scanner sees exactly what a real session saw: the right cookies, the right tokens, the real request bodies, the endpoints that actually exist. It never wanders off into pages no human reached, and it never generates speculative crawl traffic against the target.

02The pipeline — Analyze, Plan, Validate

Every module runs the same three-stage pipeline. Internally these are typed stages, and the names are worth knowing because they map onto what you see in the UI and onto how much the scanner is allowed to do:

This is what "proof replay" means in Crusader: the scanner doesn't just flag a pattern, it re-runs the captured request with a minimal, deliberate change and checks the response against the hypothesis. The first two stages are pure reasoning over data you already have, which is why they're free and safe. The third stage is the only one that touches the target, and it's the one wrapped in every guardrail in the next section.

03Passive vs active proof replay

The split between tiers falls cleanly on that pipeline.

Passive analysis (Free)

On Free, the scanner runs Analyze and Plan for every module and stops there. Most modules are analyze-only by design — they inspect headers, bodies, cookies, tokens, error pages, JS bundles, and response shapes and report what they find without ever sending a request. This is a real daily driver: passive scanning over a good capture surfaces missing security headers, cookie problems, secret exposure, stack-trace and source-map leaks, GraphQL introspection, CORS misconfiguration, and a long list of other issues with zero traffic to the target.

Active proof replay (Hunter Pro)

Hunter Pro (feature ActiveScanner) unlocks the Validate stage — but only for a deliberately small allow-list of modules where a result can be proven safely: authorization checks, some SQL injection, open redirect, prototype pollution, and JWT misconfiguration. For those, the scanner replays the planned probe against the live target and records a ProofResult. Everything else stays passive even on Pro.

04The safety model

Active proof replay is intentionally conservative. The validate stage refuses anything that isn't a safe read or a tightly-bounded canary write. It will re-request a resource as a different actor, swap an identifier, or plant a small canary value to confirm a hypothesis — it will not run destructive payloads, mass-mutate state, or improvise aggressive fuzzing. The point is a clean, minimal proof, not exploitation.

On top of that, the network layer enforces hard limits regardless of what a module asks for:

• Scope is respected. Out-of-scope hosts are blocked at connect time. The scanner only proves things against the engagement you defined in Target scope.
• Private and infrastructure addresses are blocked. Private, loopback, link-local, and cloud-metadata IPs are refused at connect time — the active scanner will not call 127.0.0.1, your LAN, or 169.254.169.254.
• DNS-rebinding protection. A hostname that resolves to a blocked address can't sneak a connection through after the fact; the connect-time guard re-checks the resolved IP.
• A budget. Active proof replay is capped at roughly a 60-second budget per run, so a scan can't spiral into a long, heavy campaign against the target.

These guards are why active scanning here feels less like a blunt instrument and more like a verifier: it does the smallest thing that proves the bug, against only the hosts you said were in play.

05The module catalog

The scanner ships a broad set of modules grouped by vulnerability class. Some run active proof replay on Pro; the majority are passive analyzers. The grouping below mirrors how findings are organized:

That list is long by design — passive analysis is cheap, so the scanner casts a wide net over each capture. You can browse the live set in the GUI under the Modules tab.

06Running it — GUI and CLI

In the GUI

Capture your traffic, then open Scanner from the sidebar. The topbar button changes with your tier: Run scan on Hunter Pro (passive analysis plus active proof replay) or Run passive scan on Free. The shortcut is ⌘R. Results land across the Scanner's page tabs:

From the CLI

Every command prints JSON to stdout, so it pipes cleanly into scripts and agents. A passive-or-active run over the current project's History:

# run the scanner over captured history, emit JSON
crusader scanner run --host target.com --json > findings.json

# scope the run and stream results
crusader scanner run --host target.com --since <id> --limit 500 --stream

# passive only — skip active proofs even on Pro
crusader scanner run --host target.com --passive --json
crusader scanner run --host target.com --no-active-proofs --json

# filter findings after the fact
crusader scanner findings --severity HIGH --module AuthzOwnership

# dry-run a module set against a saved capture file
crusader scanner test traffic.jsonl.gz

07Findings & ProofPacks

Scanner results are unified for display alongside findings from other sources (Beacon promotions, extensions, manual notes). A rich scanner finding carries a severity (Critical / High / Medium / Low / Info), a status (Confirmed / NeedsReview / Hypothesis / Dismissed), a confidence score from 0 to 1, the module, the endpoint, evidence, and optional CWE/CVSS.

Two of those fields are easy to misread, so be precise about them:

When an active proof confirms a finding, Crusader attaches a ProofPack: a self-contained reproduction artifact with a summary, the validation status, the actors involved, the evidence, a minimal reproduction, copy-ready report text, and remediation guidance. It's everything you need to reproduce and write up the bug.

08Exporting reports

Local findings are always available — review and triage them on any tier. Exporting reports requires Hunter Pro (feature Reporting). Once unlocked, you can export to a range of formats so the output drops straight into whatever your program uses:

Proof packs themselves export as .md or .pdf. The same redaction reminder applies — review what's in an export before it leaves your machine.

An honest word on SSRF

The scanner's SSRF module is strictly passive: it surfaces URL-shaped inputs as candidates and ranks them, but it never creates Beacon URLs, never replays, and never auto-verifies. Proving blind SSRF is an operator-driven flow through Beacon, not something the scanner does for you. When a candidate looks real, take it to the Blind SSRF → Beacon guide and prove it by hand.

Want a guide that isn't here yet? Email hello@crusaderproxy.com.