Business Logic Abuse
debt(d9/e7/b5/t9)
Closest to 'silent in production until users hit it' (d9). The misconception field explicitly states that automated scanners cannot catch business logic flaws — semgrep and burpsuite are listed but the detection_hints note automated=no, meaning these tools require manual, domain-knowledgeable testers. Flaws remain invisible until attackers exploit them at scale in production, e.g. issuing themselves credits through negative-quantity cart abuse.
Closest to 'cross-cutting refactor across the codebase' (e7). The quick_fix requires mapping all valid state transitions and enforcing them server-side — this is not a single patch. Common mistakes span price recalculation, rate limiting, workflow state validation, and race condition fixes across cart, checkout, discount, and inventory subsystems. Each fix touches multiple components and requires coordinated changes across the codebase.
Closest to 'persistent productivity tax' (b5). Applies to web and api contexts broadly, meaning every feature involving pricing, discounts, workflows, or inventory must be designed with server-side validation of business rules in mind. It is not architectural (b7/b9) because it doesn't define the system's shape, but it does impose ongoing discipline on multiple work streams — every new feature risks introducing a new logic flaw.
Closest to 'catastrophic trap — the obvious way is always wrong' (t9). The misconception is explicitly documented: competent developers routinely believe security scanners will catch business logic flaws, but they cannot. The 'obvious' approach of relying on automated tooling is always wrong for this class of vulnerability. Additionally, trusting client-submitted prices and assuming UI workflow enforcement equals server-side enforcement are deeply intuitive wrong assumptions that cause real financial harm.
Also Known As
TL;DR
Explanation
Business logic vulnerabilities use the application as designed but in unintended ways: negative quantities in carts (refund exploit), applying expired promo codes via replay, skipping mandatory workflow steps by manipulating URLs, race conditions on limited inventory, mass assignment of admin roles, or abusing referral systems. These are not caught by WAFs or standard security scanners because the requests are technically valid. Detection requires understanding the intended business flow and testing edge cases explicitly.
Common Misconception
Why It Matters
Common Mistakes
- Trusting client-submitted prices — always recalculate price server-side from the product database.
- No rate limiting on discount code attempts — brute-forceable codes at scale.
- Not validating workflow state transitions — user can jump from step 1 to step 5 by manipulating URLs.
- Race conditions on inventory checks — check-then-act patterns allow overselling under concurrent load.
Code Examples
// Client-controlled price — exploitable:
POST /checkout
{"items": [{"id": 42, "qty": 1, "price": 0.01}]}
// Server trusts submitted price — charges $0.01 for $99 item
// Negative quantity exploit:
{"items": [{"id": 42, "qty": -1}]}
// Cart total becomes negative — store owes the attacker// Always recalculate server-side:
public function checkout(array $items): Money {
$total = Money::zero('GBP');
foreach ($items as $item) {
// Fetch price from DB — never trust client:
$product = $this->products->findOrFail($item['id']);
// Validate quantity is positive integer:
$qty = max(1, (int) $item['qty']);
$total = $total->add($product->price->multiply($qty));
}
return $total;
}