Burp Sequencer

How Burp Sequencer works

Burp Sequencer is not just a replay tool, it is a request-timing lab. It captures a request, lets an operator control when each repeat is sent, and makes it easier to observe whether application behaviour changes when requests arrive in a particular order or with carefully chosen delays.

That timing control matters because many web application flaws do not depend on a single malformed request. They emerge when two or more requests interact across a shared state, for example when a token is reused, a session is advanced unexpectedly, or a server assumes one request will always finish before another.

What kinds of flaws Sequencer helps expose

The most useful targets are race conditions, replay-sensitive flows, and state transition bugs. These often show up where a workflow has a narrow timing window, such as double-spend style business actions, one-time tokens, confirmation steps, password reset logic, or workflows that should be single-use but are not enforced that way.

Sequencer is valuable because it helps the tester separate “request succeeded once” from “request remains safe when repeated or interleaved.” That distinction is often where application logic breaks down, especially in systems that rely on optimistic assumptions about ordering, uniqueness, or transaction boundaries.

Why request order and delay matter

Order is a security control surface. If two requests are accepted in the wrong sequence, the application may reveal inconsistent state, permit duplicate actions, or allow a request to be processed using stale assumptions. Delays can widen or narrow the window in which those mistakes appear, which makes them useful for reproducing subtle defects.

In practice, this means Sequencer is most effective when a test needs to explore concurrency, server-side locking behaviour, or token lifecycle assumptions. It is less about payload mutation and more about whether the system behaves correctly when the same action is repeated at the wrong moment or in the wrong order.

Where Sequencer fits in testing and review

Sequencer belongs in a deeper application security workflow, not as a standalone verdict. Its output should be interpreted alongside application logic review, authentication and session handling analysis, and any business rule that depends on requests being processed exactly once or in a fixed sequence.

For teams validating a suspected flaw, it is also useful for documenting the exploit condition clearly: what was repeated, what was delayed, what changed in the server response, and which state transition failed. That evidence makes remediation much easier to verify and reduces the chance that a timing bug is dismissed as a flaky test.

Risk and Threat Considerations

Race-condition weaknesses can let an attacker bypass intended sequencing, repeat a supposedly one-time action, or trigger inconsistent server state. The risk is highest where the application treats timing as an assumption rather than enforcing atomicity, uniqueness, or server-side coordination.

Failure mechanism: The server processes two or more related requests without adequate locking or idempotency, so the second request sees a stale or incomplete state and succeeds when it should fail.

Impact: The result can be duplicate purchases, token reuse, account actions executed out of order, or other state corruption that undermines integrity and trust in the workflow.

Practitioner Guidance

What to watch for: Use Sequencer when a flow depends on a single-use token, a balance-changing action, or any sequence that should only complete once. Those are the cases most likely to reveal whether the application actually enforces state on the server side, rather than relying on the client or on timing luck.

Practitioner takeaway: Treat successful replay in a sequenced test as a signal to review the underlying state model, not just the individual request.

Related resources from NHI Mgmt Group

• How should security teams use Burp extensions in application testing workflows?
• How should security teams choose between Burp-style testing and CI/CD-native DAST?
• What are the signs that secret scanning is missing important exposure paths in Burp Suite workflows?
• Why do custom Burp extensions create more value when they are tied to a specific testing workflow?