Workflow / State-Machine Testing

Purpose

Registration, verification, password reset, MFA enrollment, checkout, refund, KYC, approval, invite, subscription, file import, moderation, publishing, ticket handling - every multi-step flow is a state machine. Implementations enforce the HAPPY ORDER on the client but frequently trust each server-side step in isolation. This skill systematically abuses the machine: wrong order, repeated steps, borrowed tokens, stale states, alternate endpoints.

Entry Conditions

• A flow with 2+ sequential steps is identified, where a later step should be unreachable without an earlier one
• Step transitions are observable (tokens, status fields, changed responses, redirected routes)

Step 1: Map the Machine

For the target flow, record every step as: trigger request, resulting state marker (token, status field, cookie, response shape), and what the NEXT step expects. State markers hide in: URL tokens, hidden form fields, JSON status fields ("verified": false, "stage": 2), session attributes, and client-side route guards in JS bundles (which reveal the EXPECTED rules the backend may not enforce).

The Six Abuses

1. Step skipping

intended:  1 -> 2 -> 3 -> 4
try:       1 -> 4          (and: nothing -> 4)

Call the terminal step directly. Examples: access the dashboard with an unverified account; confirm an order without payment; hit the post-MFA landing route after password-only login; grant access without the approval step; publish without moderation.

2. Step replay

1 -> 2 -> 3, then replay 3 (or 2) again

One-time actions that can repeat: coupon redemption, vote, verification, password reset, refund. Replay the exact captured request of the completed step.

3. Reverse ordering

Call step 3 before step 2 (with markers fabricated or borrowed). Servers that check "is the token valid" but not "is the flow in the right stage" accept out-of-order transitions.