Business logic flaws: the bugs scanners can't see

Ask a scanner to find a SQL injection and it will do a decent job. Ask it to notice that a user can apply the same discount code a thousand times, or refund an order they never paid for, and it has no idea what you’re talking about. That’s the domain of business logic flaws — and they’re consistently among the most damaging issues we find.

What a business logic flaw actually is

A business logic flaw is a gap between what your application allows and what it should allow. Each individual request is well-formed and authorized. The problem is the sequence, the state, or the assumption behind it.

A few classic shapes:

• Insufficient workflow enforcement. A checkout that lets you skip the payment step and land straight on the confirmation page.
• Quantity and value manipulation. Negative quantities that credit your account, or prices sent from the client and trusted by the server.
• Replay and race conditions. Redeeming a one-time coupon many times by firing requests in parallel before the “used” flag is written.
• State confusion. Resuming a cancelled subscription’s privileges, or editing an order after it’s locked.

None of these involve a malformed payload. They involve a legitimate user doing something legitimate-looking that the business never intended to permit.

Why scanners are blind to them

Automated tools are pattern matchers. They’re excellent at signatures: known CVEs, reflected XSS, injection payloads that trigger recognizable responses. But a business logic flaw has no signature. A request that applies a discount for the tenth time looks exactly like the first — same endpoint, same shape, 200 OK.

To catch it, you have to understand what the feature is for. What is a coupon supposed to do? How many times should it work? Who should be able to cancel this order? That’s semantic reasoning about intent, and it’s precisely what automation can’t do.

How we test for them

Business logic testing starts by understanding the product, not the payload:

1. Learn the intended workflow. Walk the feature the way a real user would, and document the rules it’s supposed to enforce.
2. Enumerate the assumptions. Every rule (“a coupon works once,” “only the buyer can cancel”) is a hypothesis to attack.
3. Break the sequence. Skip steps, repeat steps, run them out of order, and run them in parallel.
4. Tamper with trusted-but-controllable values. Prices, quantities, IDs, roles, and status fields that the client can influence.
5. Prove the impact. Show the unintended outcome concretely — the free order, the escalated privilege, the double refund.

An example

On one engagement, a subscription upgrade flow validated the new plan on the server but trusted a client-sent proration_credit field. Sending an inflated credit didn’t error — it applied, zeroing the invoice. Every request was valid. No scanner would flag it. A human reading the flow saw the trusted-client-value assumption in about five minutes, and we proved it with a single modified request.

How to defend against them

• Enforce every rule server-side. Never trust the client for prices, quantities, roles, or state transitions.
• Model state explicitly. Define which transitions are legal and reject the rest, rather than assuming the UI prevents them.
• Make critical actions idempotent. Guard one-time operations against replay and race conditions at the data layer.
• Test intent, not just input. Add tests that assert business rules (“a coupon can be used once”) the way you test for injection.

The takeaway

The vulnerabilities that make headlines are rarely exotic zero-days. They’re often a valid request doing something the business never meant to allow. Finding them takes a human who understands the product and has the discipline to prove the impact — which is exactly why business logic testing can’t be automated away.