OWASP Business Logic Flaws
Some weaknesses come from broken rules, not broken code. A business logic flaw lets users bend the intended workflow of an application to gain an unfair benefit. Scanners rarely find these flaws, because every request looks valid. Understanding how the business should work reveals them.
The Loyalty Card Comparison
A café offers a free coffee after ten stamps. A customer who photocopies the card collects free coffee forever. The cashier and the stamp machine work perfectly, but the rule has a gap. Business logic flaws hide in gaps like this.
Typical Examples
| Area | Flaw | Result |
|---|---|---|
| Shopping cart | The server trusts the price sent by the browser | Items sell for a chosen price |
| Coupons | One code works unlimited times | Revenue loss |
| Quantity | Negative numbers accepted | Orders create credit instead of charges |
| Workflow | Users jump straight to the final step | Payment step skipped |
| Timing | Two requests arrive at the same moment | A single gift balance spends twice |
| Referral program | No limit on self-referrals | Endless bonus credit |
Intended Flow Versus Abused Flow
Intended: Cart → Address → Payment → Confirmation
Abused: Cart ————————————————————→ Confirmation
(payment step skipped because the server
never checks that payment happened)
Race Conditions in Plain Words
A race condition appears when two actions run at once and the application checks a rule before either action finishes. Imagine two people withdrawing the last 100 dollars from a joint account at the same second. Both checks see 100 dollars and both withdrawals proceed. Locks and atomic database operations prevent the double spend.
Why Tools Miss These Flaws
Automated scanners look for known patterns such as injected characters. Business logic abuse uses normal-looking requests in an unexpected order or amount. Only people who understand the rules of the business notice the gap, which makes design review and abuse-case thinking essential.
Prevention Techniques
- Write the business rules down in plain language. Include limits, order of steps, and who may do what.
- Recalculate prices, totals, and discounts on the server. Treat browser values as suggestions.
- Enforce workflow state on the server. Each step confirms that the previous step finished.
- Apply limits on quantity, frequency, and value for every sensitive action.
- Make coupon and reward redemption single-use with database constraints.
- Use database transactions and locks for balance changes.
- Rate limit actions that create accounts, referrals, and orders.
- Monitor business metrics for unusual spikes, such as many refunds from one account.
Abuse-Case Thinking
Teams usually write user stories about what customers want to do. Add abuse stories about what a dishonest person might try. For a gift card feature, ask these questions: What if someone redeems the same card twice at once? What if someone guesses card numbers? What if someone cancels an order after using the credit? Each answer becomes a rule or a test.
Testing Ideas
- Replay requests in a different order in a test environment.
- Submit zero, negative, and extremely large values.
- Send the same request twice in parallel.
- Remove or repeat steps in a multi-step form.
Key Takeaways
- Business logic flaws break rules, not syntax.
- Server-side enforcement of prices, state, and limits stops most abuse.
- Race conditions need locks and transactions.
- Abuse stories during design expose gaps before launch.