Business Logic Vulnerabilities: Why Scanners Cannot Find Them

Business logic vulnerabilities are the flaws where every individual request is valid, correctly authenticated and properly formatted — yet the combined result is something the business would never authorise. A discount applied twice. A negative quantity. A workflow step skipped. Because nothing is technically malformed, automated tooling has no signal to detect.

Business Logic Vulnerabilities: The Bugs No Scanner Finds

What makes a logic flaw different

Technical vulnerabilities break the rules of a protocol or language — injection, memory corruption, path traversal. Logic flaws obey every technical rule and break the rules of the business instead.

That distinction is why they survive so long in production. Static analysis has no model of your commercial intent. A scanner cannot know that a refund should never exceed the original payment, because that constraint exists only in someone's head or in a requirements document.

Recurring patterns

Workflow step skipping — going straight to the confirmation endpoint without passing through payment, because each step only checks that the previous page was rendered rather than that the state advanced.
Value manipulation — negative quantities that credit an account, prices submitted by the client, or currency substitution.
Repeat use of single-use items — one voucher redeemed many times because uniqueness is checked but consumption is not recorded atomically.
Race conditions — submitting the same request concurrently so that several requests pass the same balance check before any of them deducts.
Trusting client-side calculation — totals, tax, shipping or eligibility computed in the browser and accepted by the server.
Assumed constraints — the interface offers a maximum of ten, so the server never validates that the request asked for ten thousand.
Identity confusion in multi-party flows — acting on behalf of another party in a marketplace or delegated-access model.

Race conditions exploit the gap between check and use

Race conditions deserve special attention

Many logic flaws are really timing flaws. The application reads a value, makes a decision, then writes — and if two requests interleave between the read and the write, both pass a check that only one should have.

These are increasingly practical to exploit because sending many requests in parallel is trivial. The defence is not rate limiting; it is atomicity — enforcing the constraint in the database with a transaction, a lock or a unique constraint so that concurrency cannot produce two winners.

How to hunt for them

Start from the business rules, not the code. Write down what must always be true — a refund never exceeds the payment, a voucher is used once, a booking cannot overlap.
For each rule, ask where it is enforced. If the answer is "in the front end" or "nobody is sure", you have a candidate.
Map multi-step workflows and try entering at each step directly, out of order, twice, or with a stale token.
Manipulate every value the client can influence, including hidden fields and values that are supposedly server-controlled.
Test concurrency deliberately by firing simultaneous requests at any endpoint that changes a balance, quota or unique resource.
Test with multiple roles and multiple parties where the workflow involves more than one actor.

Finding these requires understanding the business, not just the code

Preventing them

Enforce invariants server-side and, wherever possible, in the database itself with constraints and transactions.
Model workflows as explicit state machines that reject invalid transitions, rather than as a sequence of pages.
Never accept a value from the client that the server can compute itself.
Write abuse cases alongside user stories — for every feature, ask what a hostile user would attempt.
Instrument business anomalies: unusual refund volumes, repeated voucher use and impossible sequences are often the first sign of exploitation.

Related from TechBiz Security

Sources & further reading

Frequently asked questions

What is a business logic vulnerability?

It is a flaw where legitimate, well-formed requests are combined or manipulated to produce an outcome the business never intended — such as skipping payment or reusing a single-use discount. Nothing is technically malformed, which is why it evades conventional detection.

Why can automated scanners not find them?

Scanners detect deviations from technical rules. Logic flaws break business rules that exist only in your requirements, not in any protocol specification, so the tool has no reference point for what a correct outcome looks like.

Are race conditions business logic flaws?

They frequently are. A race condition exploits the gap between checking a value and updating it, allowing several concurrent requests to pass a check only one should satisfy. The fix is atomic enforcement in the database rather than rate limiting.

How do we test for business logic flaws?

Begin by documenting the invariants that must always hold, then deliberately attempt to violate each one — skipping steps, replaying requests, manipulating values, and sending concurrent requests. This requires testers who understand the business, which is why it is manual work.

Business Logic Vulnerabilities: The Bugs No Scanner Finds