hunting-business-logic-flaws

# Hunting business-logic flaws: the bugs where every request is valid A business-logic flaw is a gap between what the code enforces and what the business intends. No request is malformed, no payload is injected, no signature is invalid; the attacker just does allowed things in a disallowed order, quantity, or combination. Scanners cannot find these, because there is no dangerous function call to flag. The danger is the sequence and the arithmetic, so finding them means modeling the intended rule first, then searching for a permitted path that breaks it. ## When to use - You are reviewing checkout, payment, transfers, refunds, or redemption. - A multi-step flow with a required order (signup, approval, provisioning). - Anything with a quota, a limit, a balance, a tier, or a one-time action. ## Scope check Test flows you own or are authorized to test. Exercise sequences against your own accounts and data; do not move real money or affect real users. If you can't name the authorization, stop. ## The loop 1. **Recover the intended rules.** For the flow under review, write down the invariants the business assumes: "a coupon applies once," "you cannot ship what you did not pay for," "a transfer cannot exceed the balance," "step 3 requires step 2." These are usually unwritten. State each explicitly, because each is a hypothesis you will try to break. 2. **Map the state machine and its real transitions.** Diagram the states and the requests that move between the...