Business Logic Testing

Purpose

Business logic flaws are rules the application MEANT to enforce but does not: prices, quantities, limits, coupons, quotas, identities, and states. Scanners cannot find them because the bug is not in a payload pattern - it is in the gap between intended rule and enforced rule. This skill teaches how to discover the intended rules black-box, then violate one assumption at a time and verify the backend actually persisted the out-of-policy outcome.

Entry Conditions

• The application has any business rules: prices, quantities, coupons, credits, quotas, trials, referrals, invites, approvals, refunds, balances, votes, subscriptions
• You can perform at least one legitimate transaction to establish a baseline

Step 1: Discover the Intended Rules

Black-box rule discovery from: UI copy ("one per customer", "limit 3", "non-refundable"), error messages on first violation (the app tells you the rule it thinks it enforces), pricing pages and ToS, how a legit transaction progresses (which fields are client-supplied vs recomputed), and client-side validation code (what the frontend refuses reveals what the backend SHOULD check).

Record each discovered rule as: rule, where observed, and the request that would violate it.

Step 2: Establish a Legitimate Baseline

Perform the transaction normally once - capture every request. The baseline tells you which parameters the client controls, what a normal response looks like, and what state changed. Never report a manipulation without having observed the legitimate behavior of the same flow.

Step 3: Identify Attacker-Controlled Variables

For each request in the flow: which values does the server accept from you? Price, total, quantity, discount, currency, role, plan, ids, coupon, timestamps, state? Any value that should be server-derived but appears client-supplied is a primary target.

Violation Catalog