Business logic abuse uses a feature exactly as built, just in a way nobody planned. Threat modeling a discount or booking flow before launch finds these cases, because scanners see only valid requests. The OWASP Top 10 uses a cinema booking example to show how a few requests can reserve hundreds of seats.
The OWASP example
In the insecure design entry, attackers model a group discount flow in a cinema booking system and discover that a small number of requests can book hundreds of seats at once. Nothing is technically broken. The design simply did not limit it.
A worked example
Imagine a store adds a promo code feature. The flow: user enters a code, the server checks it, the cart total drops.
Step 1: what are we working on? Draw the cart, the promo service, the order service and the payment step. Mark the trust boundary between the browser and your server.
Step 2: what can go wrong? Use misuse questions:
- Can the same code be applied twice, or on two carts at once?
- Can codes be combined in ways that push the price below cost?
- Can a user guess codes by trying many?
- Can the price or discount be sent from the browser and trusted?
- Can an order be edited after the discount is applied?
- Can a canceled order keep the discount value?
Step 3: what will we do?
- Apply discounts only on the server, using server held prices.
- Mark single use codes as used inside the same transaction as the order.
- Limit how many codes can be tried per account and per address.
- Cap combined discounts.
- Recalculate at payment time.
Step 4: did we do enough? Write a test for each response and ask a colleague to try breaking the flow.
Why scanners miss it
Each request in an abuse sequence is valid. Static and dynamic tools look for known bad patterns, not for a missing limit or a missing check. The OWASP entry recommends unit and integration tests that cover both use cases and misuse cases for critical flows, and limits on resource consumption per user or service.
Where to look in your own product
Search for flows where money, credits, bookings, invitations or inventory change hands. Anything with "limit" in the product spec is a candidate. So is anything where the spec has no limit at all.
Turn it into a habit
Keep a short list of misuse questions for common patterns: coupons, referrals, trials, refunds, invitations. Reuse it every time someone builds something similar.
What to watch for in logs
After launch, make abuse visible. Log rejected code attempts, repeated applications, unusual cart sizes and refunds that follow discounted orders. A review of these logs a few weeks after launch often finds the cases nobody imagined and feeds the next round of misuse questions.
Quick check
Is this a security bug or a product bug?
Both. The attacker benefits at your expense, which makes it a security issue, and the fix is a product rule.
Sources
Last reviewed: 19 October 2026.
