/business-logic-testing

name: business-logic-testing
description: "Test an authorized web application for business-logic flaws and race conditions — the classes scanners cannot find. Model invariants (conservation of value, uniqueness, monotonicity, exclusivity), build an Actor x Action x Resource matrix, abuse state machines (skip/reorder/replay steps, limit-slicing), find numeric bugs (float-vs-decimal rounding, cross-currency refund arbitrage, negative amounts), stale feature gates, and saga gaps; prove concurrency bugs (double-spend, lost update, idempotency-key reuse) with controlled parallel requests. Use when the user mentions 'business logic testing,' 'race condition,' 'double spend,' 'TOCTOU,' 'concurrency bug,' 'idempotency,' 'coupon reuse,' 'workflow bypass,' 'limit bypass,' 'negative amount,' 'refund arbitrage,' 'parallel request attack,' or 'logic flaw.'"
allowed-tools: Read, Grep, Glob

Business Logic Testing — Invariants, State-Machine Abuse, Race Conditions

The vulnerability classes scanners cannot find. A scanner matches syntax; a logic flaw is a mismatch between what the app *is supposed to guarantee* and what its code actually enforces under adversarial or concurrent use. This skill is the dynamic counterpart to `owasp-audit`'s source-side race patterns (TOCTOU, atomic queue claim, reserve-then-act) and the depth behind `web-pentest` Phase 8.

Work invariant-first: name the guarantee, then try to break it. A finding is not "I sent a weird request" — it is "I violated a stated invariant and proved durable state changed."

Authorization Check

Concurrency and logic testing mutates real state. Before sending anything:

1. Written authorization naming this specific application and that **business-logic and concurrency testing** are in scope. 2. **Prefer a staging or test-mode environment.** Use payment test mode (e.g. Stripe test keys), seeded test tenants, and disposable accounts you own. Never exercise a production money flow, inventory ledger, or third-party billing API unless the written scope explicitly names it. 3. A **request-count cap** agreed in advance. Concurrency proofs need tens of parallel requests, not thousands — name the ceiling and stay under it. 4. Accounts you control for every role and tenant you will test (owner, non-owner, admin, two tenants).

If any of these is missing, stop and ask. See **Boundaries** below.

Sending live requests is deliberately outside this skill's pre-approved tools (`Read, Grep, Glob` only) — the human runs the parallel requests, or approves each tool invocation, so a throughput test never fires unattended.

Step 1 — Model the invariants

Before touching a request, write down what the system promises. Four families cover most money and workflow bugs:

• **Conservation of value.** Money, credits, points, inventory, and quota are neither created nor destroyed except through an authorized path. A $10 refund must remove exactly $10 of credit; redeeming a coupon must decrement its remaining uses.
• **Uniqueness.** A coupon redeems once per rule; a username, invite, or idempotency key is claimed by exactly one principal; an order is fulfilled once.
• **Monotonicity.** Some counters only move one way — a used voucher never returns to unused, a shipped order never returns to pending, a consumed one-time token never re-validates.
• **Exclusivity.** A seat, a lock, a lease, or a "pending approval" row is held by one actor at a time; two parties cannot both own the same mutually-exclusive resource.

For each invariant, note **where it is enforced** (a DB unique constraint? an application `if`? only the UI?) and **what proves a violation** (a ledger that no longer sums to zero, two rows where one should exist). An invariant enforced only in the UI or only in a single handler is the lead.

Step 2 — Actor x Action x Resource matrix

Enumerate the grid and look for the cells the app forgot:

• **Actors:** anonymous, authenticated user, resource owner, non-owner, admin, two separate tenants, a user mid-workflow.
• **Actions:** create, read, update, delete, approve, cancel, refund, redeem, transfer, advance-state.
• **Resources:** each object with a lifecycle or a balance — order, invoice, coupon, subscription, document, approval request, wallet.

Fill each cell with the expected outcome (allow / deny), then test the deny cells and the state-sensitive allow cells. The interesting failures: a non-owner reaching an owner action (overlaps IDOR/BOLA — see `web-pentest` Phase 4), an actor performing an action valid only in a different state, or the same actor performing a once-only action twice.

Step 3 — State-machine abuse

Draw the intended state graph (cart -> checkout -> paid -> shipped; draft -> submitted -> approved). Then attack the edges:

• **Skip a step.** Call the step-4 endpoint directly without completing step 2. Can you reach `paid` without a charge, or `approved` without a reviewer?
• **Reorder steps.** Apply a discount after the total is locked; change the shipping address after payment authorization but before capture.
• **Replay a step.** Re-POST a terminal transition. Does "confirm" run twice? Does a one-time token validate again?
• **Limit-slicing.** A limit checked per-request but not in aggregate: split one over-limit action into many under-limit ones (withdraw the daily max in several smaller transfers; exceed a per-upload cap across many uploads that share no running total).
• **Approve your own request.** Tamper with `approver_id` / `reviewer_id` so the requester and approver are the same principal.

Each of these is a candidate for the concurrency amplifier in Step 6 — a window that is hard to hit sequentially is trivial to hit with parallel requests.

Step 4 — Numeric and value issues

• **Float vs. decimal.** Prices or balances stored or computed as floats accumulate rounding error. Probe amounts like `0.1 + 0.2`, long-fraction quantities, and values near rounding boundaries; watch for a cent appearing or vanishing.

-