Business Logic Flaws — The Bugs Scanners Never Find

Automated tooling finds bugs that violate a technical rule — a tag that renders, a query that concatenates, a header that reflects. It is blind to bugs that violate a business rule, because it has no idea what the business intended. That gap is where the most valuable, least-competed findings live.

Reconstruct the intended workflow first

You cannot break a rule you haven't identified. Before testing, write down — in plain language — what the feature is supposed to guarantee:

• "A user can only apply one signup discount, ever."
• "An order can't ship until payment settles."
• "A withdrawal can't exceed the confirmed balance."
• "Only the owner can transfer the resource, and only once."

Each of those sentences is a testable invariant. Your job is to find the sequence of requests that makes it false.

The four moves that break most logic

Nearly every logic bug we find is a variation on one of these:

1. Do it out of order

Applications assume steps happen in sequence. Skip one. Call POST /checkout/confirm before /checkout/pay. Trigger the "order shipped" webhook before the order exists. Complete a KYC flow by hitting the final step directly. State machines that trust the client to walk them in order collapse when you jump.

2. Do it too many times

Idempotency is where money leaks. Apply the coupon, then replay the exact request. Submit the refund twice in the same second. Redeem the gift card in parallel from ten connections. If the check and the write aren't atomic, races turn a one-time benefit into an unlimited one — this is the single highest-value class we hunt on commerce and fintech surfaces.

3. Do it with the wrong value

Negative quantities that credit instead of debit. A price or amount field the client shouldn't control but does. A currency swap that pays out strong currency for weak-currency cost. Decimal and rounding abuse (0.001 × 10000). Type confusion where a string where an integer was expected changes the branch taken.

4. Do it as the wrong person

Not classic IDOR on reads — logic-scoped authorization. Can a viewer trigger an owner action if they craft the request directly? Can you approve your own thing in a maker-checker flow by holding both roles? Can a downgraded account keep a privilege the UI hid but the API still honors?

Instrument value, watch state

The technique that surfaces these: capture the full request sequence for a legitimate flow, then mutate the sequence, not just single requests. Repeater tests one request; logic bugs are about the relationship between requests. Use a session that lets you replay, reorder, parallelize, and diff the resulting account state — balance, entitlements, order status — after each mutation.

Watch the numbers that matter (balance, credits, tier, quota) before and after. A logic bug is any path where those numbers end up somewhere the invariant said was impossible.

Races deserve their own pass

For anything involving a limited resource — one-time codes, balances, stock, rate limits, unique constraints — assume the check and the commit are not atomic until proven otherwise. Fire N identical requests in a tight window (single-packet techniques where the stack allows) and look for N successes where the business intended one. This one move has, on its own, produced more high-severity commerce findings for us than any other.

Proof without damage

Logic bugs are demonstrated with the smallest sequence that violates the invariant, on your own test objects, with the resulting state screenshotted. Two coupon applications on a throwaway cart. One duplicated refund of a cent to your own account, immediately reversed. You are proving the rule broke — never harvesting the consequence.

The scanner will never write this report. That's precisely why it pays.