Pentest Business Logic Abuse

Business Logic Abuse

Use When

• The main question is workflow bypass, race condition, replay, quota abuse, confused deputy behavior, or unauthorized state transition.
• A mapped workflow has meaningful business impact if steps are reordered, skipped, repeated, or delegated.

Handoff Criteria

• Hand off to pentest-web-application-logic-mapper when the workflow is not mapped well enough to test.
• Hand off to pentest-input-protocol-manipulation when parser or payload behavior becomes the main blocker.
• Hand off to pentest-exploit-execution-payload-control only after a deterministic business-logic primitive exists.

Output Schema

• Workflow model: step, required controls, bypass hypothesis
• Abuse sequence: ordered requests/events with timing notes
• Impact proof: unauthorized state change and resulting capability

Instructions

1. Model intended state transitions before adversarial testing.
2. Identify assumptions in sequencing, concurrency, and cross-system coordination.
3. Execute minimal abuse sequences that challenge those assumptions.
4. Confirm impact through observable unauthorized state or action outcomes.
5. Validate whether fixes require control relocation, not only input filtering.
6. Hand off only confirmed primitives for exploit execution.

Verification Gate

• Treat logic abuse as system-behavior testing, not payload-only testing.
• Use time-aware evidence for race and replay cases.
• Include reversible test design for stateful systems.
• Report logic flaws only with demonstrated unauthorized effect.
• Use controls for expected state, unauthorized state, and replay/race timing.
• Keep concurrency low and stop when capability is proven.