A bug-hunting workflow with Crusader

01Authorization and rules of engagement

This step is not paperwork — it is the step that keeps you out of trouble and keeps your reports payable. Before a single packet leaves your machine, read the program scope and only test what you are explicitly allowed to test. Out-of-scope hosts, third-party SaaS the target merely embeds, production data you don't own, and aggressive techniques the policy forbids are all ways to burn a program — or worse.

Pull the rules of engagement into your work surface so they're enforced, not just remembered:

• Translate the policy into Target scope — in-scope hosts in the include box, anything off-limits in the exclude box. Scope drives which traffic is stored, scanned, and surfaced, so an honest scope keeps you from accidentally fuzzing a domain that isn't yours. More on this in step 2.
• Mind the intrusive actions. Active proof replay, Beacon/OAST payloads, Intruder, and the mobile instrumentation all touch the target for real. Run them only against systems you are authorized to test, within the program's stated technique and rate limits.
• Respect "no automated scanning" clauses. Plenty of programs forbid scanners or cap request rates. Crusader's scanner runs over traffic you already captured rather than crawling, but active proof replay still sends requests — if the policy says no, keep the scanner passive.

02Capture and scope the engagement

You can't analyze what you didn't capture. The goal of this step is a single project holding the target's real traffic, with scope set so the noise falls away. Pick the path of least resistance:

Get traffic in

• Proxy + your own browser. Crusader's listener defaults to 127.0.0.1:8080 (loopback only). Point your browser there, trust the Crusader CA, and browse. The native HTTP/2 MITM captures everything — including WebSocket frames — to History regardless of intercept mode. Full setup in Getting started.
• Open test browser (the zero-install path). Launches a Chromium-family browser in an isolated profile, pre-pointed at the proxy with the Crusader root pinned by SHA-256 — no certificate install, and it works on HSTS-preloaded sites (banks, Google) that reject even a trusted user CA. This is the fastest way to a first capture. (Chromium only — Chrome/Edge/Brave/Chromium; not Firefox.)
• Import an existing project. Already have a Burp .burp, HAR, Fiddler SAZ, or Caido capture? Import it. Crusader auto-creates a project, replays the exchanges into History, and smart-seeds up to 12 Repeater tabs. The original file is never modified. Note: Burp project files only — there is no Burp XML/items import — and Burp Scanner issues, comments, and highlights don't carry over (only HTTP traffic plus reconstructed scope).
• Mobile apps. For a phone target, route the emulator or device through the proxy. Cert pinning will block you until you bypass it — see mobile cert-pinning (Hunter Pro).

Set Target scope

Open Settings → Target scope and define what's in your engagement and what isn't. You can paste host patterns (no regex required — globs like *.example.com, CIDR, path:, domain: all work) or paste a Burp Target scope JSON block straight from the program brief. Lines starting ! are exclusions.

Scope is the lever the whole workflow pulls on. It gates History storage, the scanner ("Scanner respects scope"), Repeater warnings, and intercept. An always-on tracker/telemetry blocklist already hides analytics hosts (GA, Segment, Sentry, Datadog), so your capture is signal, not ad-tech. The deep dive is in Target scope.

03Map the attack surface

With traffic captured and scope set, build a mental model of the application before you attack it. The Site Map turns your History into an endpoint tree — every host, path, and method the app exposed while you used it. This is where you decide where to spend the next hour.

The high-value views, especially with smart flags (Hunter Pro):

• Ghost / untested endpoints — paths the app referenced (in JS, links, or API responses) that you never actually exercised. These are the corners nobody clicks, and they're where forgotten authorization checks live.
• Mutating endpoints — anything that writes: POST, PUT, PATCH, DELETE. State changes are where access-control and mass-assignment bugs hide.
• Auth-gated endpoints — the surface that's supposed to require a session. These are your IDOR/BOLA candidates for step 5.

From the CLI you can slice the same tree for triage or scripting:

# surface the interesting subsets of the map
crusader sitemap --untested        # referenced but never hit
crusader sitemap --mutating        # state-changing endpoints
crusader sitemap --idor            # IDOR-shaped candidates (smart flags = Pro)

Use the map to drive more capture: walk every feature, every role, every "edit / delete / export / invite" button. The richer the History, the better every later step works — the scanner, Shadow Replay, and the agent loop all read from what you captured. Browse with intent now so you're not guessing later.

04Triage passively for cheap wins

Before you start crafting attacks by hand, let the passive scanner read everything you captured and hand you the free findings. This is the highest reward-per-second step in the whole loop, and it's Free.

The Crusader scanner is not a crawler — it runs over already-captured History. In the Scanner screen, click Run passive scan (Free) or Run scan (Hunter Pro adds active proof replay). Most modules are analyze-only and never touch the target. Then read the results across the page tabs — Findings, Authz, Intelligence, and Probe queue.

Cheap wins to harvest first — each is a real report on many programs:

• Security headers and cookie flags — missing HSTS, weak CSP, cookies without HttpOnly/Secure/SameSite. Low severity, but fast and often accepted.
• Secrets and info leak — API keys in URLs, secrets baked into JS bundles, source-map leaks, dependency disclosure, internal IPs. The Intelligence tab is where these surface.
• Debug endpoints and stack traces — verbose errors, debug routes, stack-trace leaks. Frequently a foothold for something bigger.
• GraphQL introspection — if introspection is open, you've just been handed the schema for authorization testing.

Run the same triage from the CLI when you want it scripted or piped into other tools:

# passive triage over captured history, JSON to a file
crusader scanner run --passive --json > findings.json
crusader scanner findings --severity HIGH

05Hunt authorization bugs — the money class

If you do one thing well, make it this. Broken object-level authorization (IDOR/BOLA) and broken function-level authorization are the highest-ROI bug class in modern web and API targets: they're everywhere, they're high severity, and scanners alone rarely confirm them because the tool can't know that record 1043 belongs to a different tenant. You bring that knowledge; Crusader does the mechanical replay.

The method is simple and devastating: take a request that works for one user, and replay it as another.

1. Capture two identities. Log in as user A and user B (ideally in two tenants/orgs), browsing both through the proxy so each session lands in History. Save each as an Identity — Crusader stores cookie / bearer / API-key / client-cert auth, host-scoped and scope-aware.
2. Replay as the other identity. For a quick check, use Replay as… to re-send a single request with a different identity backfilled. If A's request for /api/orders/1043 still returns A's order when sent with B's session, that's an access-control failure.
3. Shadow Replay for scale. Identity Shadow Replay (Hunter Pro) re-issues captured requests across identities and diffs the responses — it surfaces authorization drift, where two actors get materially different (or identical) responses they shouldn't. This is how you sweep dozens of endpoints for BOLA at once instead of one curl at a time.

What "different" should mean: B should get 403/404 on A's objects. A 200 with A's data — or an anonymous request returning authenticated content — is the bug. The full workflow, including how to capture and scope identities cleanly, is in Identities & Shadow Replay.

06Prove it — active replay and OAST

A candidate isn't a finding until it reproduces. This step turns a hunch into evidence, with the right instrument for each class. Everything here sends real requests to the target — authorized systems only.

Active proof replay (confirmable classes)

For classes Crusader can safely confirm, Run scan (Hunter Pro) does active proof replay: it forms a hypothesis, plans a probe, and validates it. This runs only for an allow-list — authorization, some SQLi, open redirect, prototype pollution, JWT misconfig — is budget-capped (~60s), and refuses anything that isn't a safe read or a tightly bounded canary write. Out-of-scope hosts and private/loopback/metadata IPs are blocked at connect time, with DNS-rebinding protection. A confirmed active finding ships with a ProofPack (see step 7).

Beacon / OAST (the blind classes)

The bugs that never show in a response — blind SSRF, blind XXE, blind SQLi, out-of-band RCE — need an out-of-band oracle. Crusader's Beacon (Interactsh under the hood) gives you a callback host: plant it in a suspected sink, and when the target resolves or requests it, the hit lands in your feed.

1. In Beacon, pick a provider — hosted Crusader.sh (Hunter Pro) for zero setup, or a Custom BYO server (Free).
2. Set a PAYLOAD PURPOSE (e.g. ssrf) and copy a DNS, HTTP, or SMTP payload.
3. Insert it into the suspected sink — a url/webhook/callback/fetch param, a link-preview, an XML entity — and send it via Repeater, Intruder, or the browser.
4. Catch the callback and Promote to finding.

Manual depth — Repeater and Intruder

Some bugs only fall to hands on the request. Repeater is your manual replay bench — edit any request, set a per-tab identity, resend, and read the diff. Intruder (Attack Studio) is for volume: Sniper mode is Free (capped at 2000 requests); Battering ram / Pitchfork / Cluster bomb and the uncapped run are Hunter Pro. Use them to fuzz parameters, brute IDs around an IDOR, or grep responses for a tell.

07The vuln-class playbook

Where Crusader helps for each common bug class, and the deep-dive doc to read next. Remember the through-line: the tool surfaces and replays; you confirm.

08Write it up

A bug you can't reproduce on demand is a bug you can't get paid for. Crusader keeps findings in one place and packages the evidence so the report writes most of itself.

• Triage in Findings. The Scanner → Findings view unifies scanner findings and the thin findings that Beacon/manual flows create. Mark each Confirmed, NeedsReview, or Dismissed — that status, not the confidence number, is what you stand behind.
• Lean on ProofPacks. A confirmed active finding carries a ProofPack: a summary, validation status, the actors involved, evidence, a minimal reproduction, copy-ready report text, and remediation. It's the reproduction artifact a triager needs.
• Export the report (Hunter Pro). Local findings are always available; exporting reports is Hunter Pro. Formats include Markdown, HackerOne Markdown (.h1.md), Jira Markdown (.jira.md), SARIF, JSON, and CSV; ProofPacks export as .md / .pdf.

09Scale and automate

Once the manual loop is second nature, push the repetitive parts into scripts and agents. Everything below is driven by the same project, scope, and History you've been building.

CLI and CI

Every Crusader command prints JSON to stdout and errors to stderr with a non-zero exit, so it pipes cleanly into scripts and CI. Re-run triage on every capture, gate a build on findings, or fan a sweep across hosts:

# scripted triage in CI — active scan needs a target scope set, or it hard-fails
crusader scanner run --host target.com --json > findings.json
crusader findings list --severity HIGH

# replay captured rows with saved identities for access-control drift
crusader hunt run

Note that hunt run replays existing History rows with your saved identities — it needs captured traffic and at least one identity, and it is not a URL probe. The full command surface is in the CLI reference.

The MCP agent loop

Crusader ships an MCP server (crusader mcp serve, stdio) so a coding agent like Claude Code can drive your workspace. The read-only tools are Free (search History, read the Site Map, list scope and identities, ask for the next move); the write tools — replay, scan, hunt, create findings — are Hunter Pro.

The intended loop is passive-first and never auto-fires network actions: agent.guide to orient, then memory extraction, a ranked agent.next_move, and a plan you commit as a task pack. Plan commits write a task pack — they don't execute traffic on their own. Wire it up and learn the loop in MCP with Claude Code.

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