Business Logic Flaws

A business logic flaw is a bug in what the application is allowed to do, not in how it parses input. The payload is ordinary, valid data — a price, a coupon code, a quantity — used in a way the designer did not intend. Scanners rarely find these, because nothing is malformed; only someone who understands the workflow spots that a step can be skipped, repeated, or reordered to their advantage.

What is the vulnerability?

Three classic shapes, all in the labs:

• Trusting client state for a decision. The checkout accepts the price from the request. Edit it, pay a feather.
• Missing idempotency. A one-time welcome voucher is never marked used, so redeeming it ten times credits you ten times.
• Unbounded combination. Percentage coupons are summed with no cap, so stacking them past 100% makes the total negative.

Why does it happen?

The code works perfectly for the honest path the developer tested. The flaw lives in the paths they did not: resending the same request, changing a value the UI treats as fixed, combining features that were never meant to combine. There is no “injection” to filter — the data is valid.

How do you stop it?

Enforce the rules on the server, where the attacker cannot reach: look prices up, never accept them; make one-time actions atomically consume a token; cap and forbid-stack discounts and never let a total fall below zero. Think adversarially about every workflow — what if this step runs twice, out of order, or with a value the UI would never send?

The three labs below are exactly these: tamper a price, reuse a voucher, and stack coupons to zero.