A business logic flaw is a way of using a legitimate workflow, such as checkout or refunds, to cause harm to the business. The code works as written but the rules are incomplete. Automated scanners often miss them, so reviewing the workflow with questions is the practical method.
Definition
OWASP describes business logic vulnerabilities as ways of using the legitimate processing flow of an application with a negative consequence for the organization. Its examples include a product being released before the transaction is verified. It gives a rule of thumb: if you need to truly understand the business to see the vulnerability, you may have a business logic problem. It also notes these flaws are hard to find automatically because they involve legitimate use of the application, and can be among the most critical in consequence.
OWASP lists related abuse for stores: bypassing purchase validation, refund abuse, discount stacking, modifying orders after approval, reserving stock without buying, and applying expired coupons repeatedly.
Ten questions to run against your checkout
- Does the server recompute price, tax and shipping at the final step, or does it trust values sent from the browser?
- Can the quantity be zero, negative or very large?
- Can an order be edited after payment is authorized?
- Can a coupon be stacked, reused or applied after it expires?
- Can two simultaneous requests redeem the same code? See how promo code race conditions work.
- Is goods release tied to a verified payment event? See why fulfilment should not depend on the thank you page.
- Can a refund exceed the amount paid, or be issued twice?
- Can a buyer reserve limited stock without paying, and does the hold expire?
- Can steps be skipped by calling a later endpoint directly?
- Would anyone notice if these rules failed? Is there reconciliation between orders, payments and shipments?
Controls OWASP suggests
Enforce strict workflow validation, keep state validation on the backend, include business process modeling in security reviews, apply rate limiting and anti automation controls, use transaction auditing and reconciliation, and bring business analysts into threat modeling sessions.
How to run the review
Gather a developer, someone from operations and someone from finance for an hour. Walk the order lifecycle step by step and ask what each actor could do out of order. Write down each gap as a test case, and add it to your automated tests so it stays closed.
Quick check
Why do scanners miss these flaws?
They use normal features in an allowed way, so nothing looks malformed. Finding them needs knowledge of the business rules.
Who should own the review?
Shared ownership works best: engineering writes the tests, and operations and finance define what abuse looks like.
Sources
Safeguard's policies and gates can enforce checks on checkout code changes before merge, and the free scan is at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
