Repeater — precise manual replay

01What Repeater is for

Some bugs only show up when you change one thing and send the request again. Bump an id, drop a header, swap a token, rewrite a JSON field — then read what comes back. Repeater is where you do that: a single request, edited by hand, sent on demand, with the response sitting next to it.

It's the deliberate counterpart to the proxy. HTTP History records everything that passed through; Repeater is where you pull one of those exchanges out and work it. Each request opens in its own tab, so you can keep several lines of inquiry side by side — one tab probing an IDOR, another testing an auth header, a third shaping a GraphQL query.

02Send a request to Repeater

Repeater tabs start from a real captured request, so you're never typing one from scratch. The usual path:

1. Open HTTP History from the sidebar and find the exchange you want to work — the search bar and column sort help you narrow down.
2. Right-click it and send it to Repeater. The request opens in a new Repeater tab, headers and body intact.
3. Switch to Repeater in the sidebar (under Tools) and start editing.

You can also seed Repeater straight from the command line by history ID — handy when you already know the row you want, or when an agent or script is driving:

# open History row 482 as a Repeater tab
crusader repeater send 482

Like every Crusader command, this prints JSON to stdout, so it composes cleanly with the rest of your tooling. To find the ID first, list or search History:

# newest first, by request number
crusader history list --sort number --desc --limit 20

# or search, then send the row you want
crusader history search "/api/users" --sort date --desc --limit 20

03The request views

The same request can be edited through five views. They're tabs over one underlying request — switch freely; an edit in one is the same edit everywhere. Pick whichever makes the change you're about to make obvious.

All five views carry syntax highlighting, so structure stays legible while you edit. The structured views (Headers, Params, Body, GraphQL) keep you from accidentally corrupting the request; Raw is there for when corrupting it on purpose is the point.

04Replay as an identity

The single most useful thing Repeater does for access-control work: replay the same request as a different account. Instead of pasting cookies and bearer tokens by hand each time, attach a saved identity to the tab and Crusader applies that auth material when it sends.

Identities are saved auth that's host-scoped and scope-aware — a cookie, a bearer token, an API key, or a client cert. Set one as the per-tab identity in Repeater and the request goes out as that user. Send the request as admin, switch the tab's identity to a low-privilege account, send it again, and compare the two responses — that side-by-side is how you prove (or kill) an IDOR or a broken-authorization finding.

You can drive the same idea from the CLI while building or saving identities:

crusader identity list
crusader identity use <identity-id>

Authorized testing only — replaying as another identity is for accounts and systems you're cleared to test.

05mTLS client certs

When a target demands a client certificate, a normal replay fails the TLS handshake. A failed mTLS handshake (a bad_certificate or certificate_required from the server) raises an mTLS REQUIRED toast telling you the host wants a client cert — and pointing you at mobile capture to pull one.

If you have an extracted client cert saved as an identity (kind mTLS client cert, carrying the PEM cert and key), the flow in Repeater is the same as any other identity:

1. Open the failing request in Repeater.
2. Set the per-tab identity to the captured mTLS identity.
3. Send — Crusader presents that client cert in the TLS handshake.

06Resend and read the response

Once the request looks right, send it. The response comes back in the tab — status line, headers, and body — and you read it directly: status code, what changed, what leaked, what got rejected. Edit, send, read, repeat. That tight loop is the whole point of the tool.

Because each tab is independent, you can keep one request stable as a baseline and mutate a copy in another tab, sending each on its own. Nothing fires until you hit send — Repeater never replays on its own.

Repeater traffic is recorded too: requests you send here land in HTTP History tagged with source = repeater, so a sent request is never lost and you can pull it back up — or query it later in SQL.

07Compare two responses

Reading two responses by eye works until they're long or nearly identical. When the difference is what matters — admin vs. low-priv, before vs. after one edited field — diff them.

Comparer (under Tools) puts two items side by side and highlights what changed. From the CLI you can diff two History exchanges by ID:

# side-by-side diff of two captured exchanges
crusader compare 482 487 --side-by-side

# or a unified diff
crusader compare 482 487 --unified

This is the natural close to an identity test: send as actor A, send as actor B, then diff the two responses. A body that should differ but doesn't — or one that shouldn't but does — is your signal.

08Scope & safety

Repeater respects your engagement boundaries. If you've set a Target scope, Repeater warns on out-of-scope requests before you send something at a host that isn't part of the engagement — a guard against a fat-fingered hostname hitting production you weren't cleared to touch.

Everything Repeater does is explicit and operator-driven: it sends only when you send, against the request you edited, as the identity you chose. Keep it pointed at systems you're authorized to test, and it's a precise instrument for exactly that.

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