Research

A valid request that is wrong only in your app.

Business logic flaws don't break the rules of HTTP — they break the rules of your business. A negative quantity that credits an account, a step skipped to dodge payment, a coupon redeemed twice in a race. Every request is well-formed, so no scanner signature fires. Here is why they're invisible to automation, and how we test them against your application's own rules.

Research · 24 October 2026By Enes Çetinkaya

The short version: a business logic vulnerability is a legitimate request the application should not have honoured, judged against what the app is for rather than against a generic pattern. Because the rule being broken is specific to your product, no signature detects it — testing requires understanding the workflow, forming hypotheses about how each rule could fail, and proving the break by reproducing it.

What a business logic vulnerability is

Most vulnerability classes are defects in the plumbing: a bad query string, an unescaped field, a missing check. A business logic flaw is different — the plumbing works perfectly, and the application does exactly what it was told. The problem is that it should not have been willing to do it. The gap is between the behaviour and the intent of the workflow, and intent is something only your application defines.

Each request on its own: authenticated · well-formed · 200 OK 1 · Add to cart POST /cart 2 · Charge POST /pay 3 · Confirm POST /confirm 4 · Ship POST /ship then then then payment never called attacker’s order: skip step 2 The invariant that breaks Rule: order.paid must be true before order.status = shipped Result: a valid, 200-OK sequence ships an unpaid order No single request is malformed — only the ordering violates intent
A business-logic flaw hides in the sequence, not the request: every call here is authenticated, well-formed and returns 200, yet reordering them to skip the payment step ships an unpaid order — breaking a rule no single request violates.

The common shapes

  • Sign flips and bounds — a negative quantity or price that turns a purchase into a credit; a discount over 100%.
  • Skipped steps — jumping straight to the confirmation endpoint to bypass a payment or verification step the UI enforces but the server does not.
  • Race conditions — redeeming a one-time coupon, withdrawing a balance, or converting a trial twice by firing requests in parallel before the first finishes.
  • Replay and reuse — re-submitting a signed request, a token, or a one-time action that was never invalidated.
  • State-machine shortcuts — moving an object to a state it should only reach through a path you skipped (shipping an unpaid order, approving your own request).

Why scanners can't see them

A scanner matches generic patterns against one request at a time. It has no idea that an order total should never be negative, that a trial should convert once, or that this endpoint should be unreachable until payment clears — because those facts live in your business, not in a signature database. To a scanner, a request that credits an account looks exactly like one that debits it: a clean 200. The bug is only visible to something that knows the rule, and the rule is yours.

How we test business logic

Because the oracle is your application's own rules, the test is built from them. The engine learns the authorized application's workflows, roles, data ownership and tenant boundaries, then forms specific, testable hypotheses: "if quantity accepts a negative, the balance should move the wrong way," "if the confirm endpoint is callable without the pay step, the order ships unpaid." It runs those as controlled experiments using the test identities you supply, watches whether the invariant actually breaks, and — on a success — reproduces it from a clean session before recording it. The business rule, the controlled test, the clean-session proof and the impact travel with the finding as hash-chained evidence.

Honest limits

Logic testing is bounded by what the engine can learn about your workflows and by the identities and surface you authorize. Proving one invariant can be broken does not prove the rest hold, and a clean result means the rules we tested held on the paths we reached — not that the application's logic is flawless. We report coverage as evidence: which workflows and roles were exercised, and which were out of reach, so the result is an honest account of what was actually tested.

FAQ

What is a business logic vulnerability?

A flaw in how an application's intended workflow can be abused — a negative quantity that credits an account, a skipped payment step, a coupon redeemed twice. The request is valid; it is only wrong relative to what the app is for, so no generic signature detects it.

Why can't a scanner find them?

A scanner matches generic patterns and has no model of your rules. It cannot know an order total should never be negative or a trial should convert once, because those rules live in your business. Testing them needs an understanding of the workflow and hypotheses specific to it.

How does SuperPentest test business logic?

It learns the application's workflows, roles and ownership from the authorized scope, forms specific hypotheses about how each rule could break, runs controlled tests as the identities you supply, and reproduces any success from a clean session before recording it.

Related reading: the access-control teardown, the prompt-injection canary, or a full worked finding. Or book a demo.