Bridge WAF
Business logic flaws: valid requests, wrong outcome
A business logic flaw is a weakness in the rules an application enforces, not in how it handles input. Every request is well formed, nothing is injected, and the application does exactly what its code says: it accepts a negative quantity, lets a step be skipped, applies a discount twice, or processes two requests at once in a way nobody planned. That is what makes these flaws the hardest to catch from outside.
Quick facts
- OWASP category
- A06:2025 Insecure Design, which lists CWE-362 (A06 page); see OWASP Top 10
- What requests look like
- Ordinary: valid values, valid sessions, valid order of calls, or nearly so
- Where it is fixed
- In the design and the server-side rules of the application
- Does a WAF stop it?
- No. There is no attack pattern to match; rate limits blunt some abuse
Testing approaches follow the OWASP Web Security Testing Guide.
Business logic vulnerability examples
- Negative or extreme values. A quantity of minus one turns a charge into a refund; a huge one overflows a total.
- Skipped steps. Calling the final step of a checkout without the payment step in between.
- Reused one-time items. Applying a single-use coupon or gift card many times.
- Trusted client values. A price, discount or role sent by the browser and accepted by the server.
- Limits that reset. A daily limit that can be avoided by changing a field the counter is keyed on.
None of these needs special characters. The request is wrong only in what it means to the business.
Race conditions
A race condition happens when two requests act on the same data at the same time and the application checks and updates in separate steps. Two withdrawals both read the same balance, both pass the check, and both succeed; a single-use code is redeemed twice because both requests saw it as unused.
Attackers send many identical requests in a very short window to find these gaps. The fix is to make the check and the update one atomic operation, with database constraints, locks or idempotency keys.
Where logic flaws cluster
Checkout and payment flows, with prices, discounts, quantities and refunds. Account flows, with sign-up, password reset, email change and invitations. Anything with a limit or a quota, from free trials to referral rewards. And workflows with several steps, where each step assumes the one before it happened.
These are also the places attackers profit from most, which is why a review of the rules behind them pays back more than a general scan.
Why a WAF cannot see logic flaws
A request filter decides from what a request contains. A logic flaw is in what a request means in context: whose order it is, which step came before, what the balance was a millisecond ago. None of that is in the request.
Rate limits help at the edges, for example by slowing the bursts that race conditions need, but the flaw remains. This is the clearest case of the boundary described on web attacks.
How to find and prevent logic flaws
- Write down the rules. Allowed values, the order of steps, who may do what, and how often.
- Enforce every rule on the server. Never trust prices, roles or step markers from the client.
- Make check-and-update atomic. Constraints, transactions or idempotency keys for anything that can be raced.
- Test with abuse cases. Negative values, repeated and parallel requests, steps out of order.
- Review with people who know the business. Tools cannot tell a discount from a bug; colleagues can.
Questions
What is a business logic vulnerability?
A weakness in the rules an application enforces, so valid, well-formed requests produce outcomes the business never intended, such as negative prices, skipped steps or reused coupons.
What is a race condition vulnerability?
A flaw where two simultaneous requests both pass a check before either updates the data, so an action meant to happen once happens twice.
Can a WAF prevent business logic attacks?
No. The requests contain no attack pattern; the flaw is in what they mean in context. Rate limits can slow some abuse, but the fix is in the application.