Docs / Core / Target scope
Target scope & safety
The short version. Scope is the single declaration of what's in your engagement and what isn't. Open Target scope from the sidebar (or Settings → Target scope), paste in-scope URLs or host patterns — no regex required — or paste a Burp Target scope JSON, and add exclusions in the separate exclude box. Scope decides which traffic is stored, scanned, and surfaced. It also powers the deeper safety gate: active scans and identity replay only ever touch authorized, non-internal hosts — out-of-scope hosts are blocked, and private, loopback, link-local, and cloud-metadata addresses are blocked at connect time, so a vulnerable target can't be turned into a pivot against your own network.
01Why scope matters
Scope is the contract between you and the engagement. In Crusader it does double duty: it keeps your workspace clean — only the hosts you care about get stored, scanned, and surfaced — and it draws the boundary that the active tooling will not cross. The in-app description is exact: "What's in your engagement and what isn't. Affects which traffic gets stored, scanned, and surfaced."
Getting scope right early pays off twice. A tight include list means History isn't drowning in third-party noise, and the scanner spends its budget on your target instead of someone else's CDN. A correct exclude list means you never accidentally probe a staging system, a shared dependency, or a host the program explicitly carved out.
Everything Crusader does actively — active scans, intruder, identity replay — is for systems you are authorized to test. Scope is how you tell the tool where that authorization begins and ends. Set it before you run anything intrusive.
02Set your scope
Open Target scope from the sidebar, or go to Settings → Target scope. There are two separate boxes: one for what's in scope (include) and one for what's out (exclude). You don't need regex for either — paste plain URLs or host patterns, one per line.
Paste URLs or host patterns
The fastest start is to paste the origins you're testing. Crusader treats each line as a rule (see the syntax below), so a bare hostname or a wildcard host is enough:
# in the include box — one rule per line
app.example.com
*.example.com
https://api.example.com/v2/Paste a Burp Target scope JSON
Coming from Burp? Paste your exported Target scope JSON directly into the box and Crusader converts its include/exclude rules into its own glob patterns — you'll see a confirmation like imported 8 scope / 2 exceptions. This is scope-only; it does not import any traffic.
Burp Target scope JSON is the only Burp scope format Crusader reads here. It is separate from importing a full Burp project (.burp) for its traffic — see Getting started for that path.
Add exclusions
Put exclusions in the dedicated exclude box, or prefix a line in either box. A line starting with ! (or exclude: / out:) is an exclusion; a line starting with allow: overrides the always-on blocklist for a host you genuinely need to see:
*.example.com
# carve out a host you must not touch
!admin.example.com
exclude:legacy.example.com
# force-show a host the tracker blocklist would hide
allow:analytics.example.com03Rule syntax
Each line is one rule. A bare host or wildcard covers most engagements; the prefixes below let you be precise about what part of a request a rule matches. Prefix a rule with !, exclude:, or out: to make it an exclusion.
| Form | Matches |
|---|---|
| Host glob | *.example.com — the host and any subdomain. A bare app.example.com matches that host. |
| CIDR | 198.51.100.0/24 — any host whose IP falls in the range. |
host: | host:api.example.com — match on hostname explicitly. |
domain: | domain:example.com — the domain and its subdomains. |
path: | path:/api/ — match on the request path. |
url: | url:https://example.com/admin — match on the full URL. |
regex: / re: | regex:^https://[a-z]+\.example\.com/ — a regular expression, for when globs aren't enough. |
Regex is available but optional. For the vast majority of engagements, host globs and CIDR ranges in the include box plus a few ! exclusions express the whole boundary.
04What scope affects
Scope is not just a display filter — it changes how several tools behave. Each of these has its own setting so you can tune how strict the boundary is:
| Area | Effect |
|---|---|
| History storage | Show out-of-scope in History is off by default, so out-of-scope traffic is kept out of view; out-of-scope response bodies can be dropped too. |
| Scanner | Scanner respects scope — analysis and any active proof replay stay on in-scope hosts. |
| Repeater | Repeater warns on out-of-scope — you get a warning before firing a request at a host outside scope. |
| Intercept | Restrict to in-scope — limit interception to hosts inside your scope. |
Independent of your scope, an always-on tracker and telemetry blocklist hides analytics and monitoring hosts — Google Analytics, Segment, Sentry, Datadog, and the like — so they never clutter your workspace. Use an allow: rule if you actually need to inspect one of them.
05The safety gate
This is the part that makes Crusader safe to point at a live target. Passive analysis reads only what you already captured, but anything that sends traffic on its own — active proof replay in the scanner, and identity replay — passes through a hard safety gate before a single packet leaves your machine. The gate enforces two rules, and there is no setting that turns it off.
Authorized hosts only
Active actions run only against hosts that are in scope. An out-of-scope host is blocked outright — the scanner will not "wander" to a domain you didn't authorize, even if a captured request points at one. This is what keeps active replay aligned with the engagement boundary you set above.
No internal addresses — checked at connect time
Even for an in-scope host, Crusader blocks connections to private, loopback, link-local, and cloud-metadata IP addresses at connect time. The check happens on the resolved address, not just the hostname, which means it also defeats DNS rebinding — a hostname that resolves to a public IP on first lookup and a 169.254.169.254 or 127.0.0.1 on the next can't slip a connection through. A vulnerable target cannot be used to pivot Crusader into your own network or a cloud metadata endpoint.
Only safe reads and bounded canary writes
Active proof replay is deliberately conservative. Most scanner modules are analyze-only; the few that replay run within a budget cap and refuse anything that isn't a safe read or a tightly bounded canary write. The scanner never auto-verifies destructive behavior — for example, the SSRF module is strictly passive and never creates callbacks or fires probes on its own (you prove SSRF yourself with Beacon).
The takeaway: scope plus the connect-time IP guard mean active scans and identity replay touch only authorized, externally-routable hosts. That is a property of the tool, not a checkbox — but it still assumes you have permission to test the hosts you put in scope.
06Empty scope & the CLI
Be deliberate about leaving scope empty. An empty scope means everything is in scope — every host you browse through the proxy is stored and eligible for passive analysis. That's convenient for early recon, but it removes the boundary that the warnings and the active gate rely on, so set a real scope before you run anything intrusive.
The CLI is stricter on purpose. An active scan from the CLI hard-fails without a scope set — there is no implicit "scan everything" for active proof replay:
# active scan — requires a target scope, or it hard-fails
crusader scanner run --host target.com --json > findings.json
# inspect and manage scope from the CLI
crusader scope listIf you want passive-only behavior without a scope, run the scanner in passive mode (--passive / --no-active-proofs); the hard-fail applies specifically to active proof replay, which is the part the safety gate governs.
07Next steps
With scope set, you're ready to capture, scan, and replay safely. These pick up where this guide leaves off:
Want a guide that isn't here yet? Email hello@crusaderproxy.com.