Business Logic Vulnerability
debt(d9/e7/b7/t9)
Closest to 'silent in production until users hit it' (d9). The detection_hints explicitly state automated: no, and the misconception confirms that automated scanners miss these flaws entirely. Tools listed (phpstan, deptrac) catch structural placement issues but not the semantic correctness of business rules. Flaws like applying a discount twice or skipping a payment step are only discovered when users or attackers exploit them in production.
Closest to 'cross-cutting refactor across the codebase' (e7). The quick_fix states business rules must be moved into domain objects and use cases — away from controllers, templates, and stored procedures. The common_mistakes show the problem is systemic: client-submitted values trusted everywhere, multi-step workflow assumptions spread across the app, access control at the UI layer. This is not a single-file fix; it requires reorganising where business rules live across the entire codebase.
Closest to 'strong gravitational pull' (e7). The term applies_to all contexts: web, cli, and queue-worker — broad reach. Business logic placement shapes every feature and workflow added to the system. Misplaced logic in controllers, templates, or triggers creates a persistent structural tax where every future developer must know which layer actually enforces rules, and every new feature risks adding more misplaced logic.
Closest to 'catastrophic trap — the obvious way is always wrong' (t9). The misconception is explicit: developers believe automated scanners find business logic flaws, but they never do. The common_mistakes reinforce this — trusting client-submitted prices, assuming workflow order, implementing access control only at UI — all represent the intuitive approach that is systematically wrong. Competent developers routinely make these mistakes because the violations look like working code.
Also Known As
TL;DR
Explanation
Business logic vulnerabilities are not caused by coding errors like injection flaws but by incorrect assumptions about how users will interact with the application — such as assuming a multi-step workflow will always be followed in order, that prices are always positive, or that quantity fields won't accept negative values. These flaws are largely invisible to automated scanners because the logic is application-specific. They require careful threat modelling, code review, and test cases that explicitly verify invariants.
How It's Exploited
# If server trusts client price, attacker buys £500 item for 1p
Common Misconception
Why It Matters
Common Mistakes
- Not testing negative flows: what happens if a user skips payment step, applies a coupon twice, or changes quantity after pricing?
- Trusting client-submitted prices, totals, or discount codes without server-side recalculation.
- Assuming multi-step workflows are always completed in order — attackers skip steps by crafting direct requests.
- Implementing access control at the UI layer but not re-validating it in the API handler.
Code Examples
// Trusting client-supplied price
$item = Product::find($req->product_id);
$price = $req->price; // attacker sends price=0.01
Order::create(['price' => $price, 'product_id' => $item->id]);// Always compute price server-side from authoritative source
$item = Product::findOrFail($req->product_id);
$price = $item->currentPrice(); // from DB, not the request
Order::create(['price' => $price, 'product_id' => $item->id]);
// Apply discounts server-side too
$coupon = Coupon::findValid($req->coupon_code);
$final = $coupon ? $coupon->applyTo($price) : $price;