Earthshaker Security Book a scan

← All field notes

Business logic 8 October 2026 · 10 min read · Caleb

Stop Double Spend: Fix 3 Business Logic Flaws Engineers Overlook

Compact technical guide for engineers to detect and prevent business logic flaws. Learn OWASP state models, SeGa semantic tests, atomic DB fixes, and...

Business logic security article title card

Business logic flaws are application-specific failures where legitimate workflows or state transitions get abused to produce unintended effects, not bugs in syntax or input parsing but abuse of valid application behavior. They stem mainly from race conditions, missing server-side state validation, and broken authorization checks. The core fix is architectural: enforce server-side state machines and atomic database operations so no request can skip a step or act on stale data.

TL;DR:

  • Business logic flaws often result from race conditions, missing server-side validation, or broken state checks, and can be exploited even with perfectly validated inputs.
  • Common attack patterns include double-spending, coupon stacking, role escalation during setup, and forging hidden fields, often exploiting timing gaps or stale data.
  • Detecting these flaws requires manual testing, concurrent request testing, and formal state machine modeling, not just automated scanners.
  • Implementing atomic database operations, server-side state machines, idempotency keys, and proper revalidation effectively mitigates logic-based vulnerabilities.
  • Prioritize verifying critical workflows, such as payments and role changes, to prevent race conditions that attackers can exploit before addressing broader issues.

Table of Contents

What makes a flaw a business logic issue, not a code bug

A business logic flaw passes every syntax check, every type check, and every input sanitizer, yet still lets someone redeem a coupon twice or ship an order before payment clears. The cleanest way to reason about these issues is the finite-state model that OWASP's business logic testing guidance uses: treat the application as a set of states, transitions between them, and the memory that tracks where a given user or object currently sits. A flaw exists wherever a transition can happen out of order, twice, or without the prerequisite state being true.

Finite-state model showing invalid workflow transitions

Three signals usually point to a logic flaw rather than a plain injection or validation bug. First, workflow endpoints are reachable directly, bypassing the UI sequence that was meant to enforce order. Second, a critical field such as price, role, or quantity is editable or inferable from the client side. Third, the same object can land in inconsistent states depending on which request arrives first, a sign that transitions are not being validated against the object's actual current state.

Root causes: race conditions, state tampering, and missing transition checks

Most business logic flaws trace back to a handful of root causes, and mapping a finding to one of them makes remediation far more concrete than describing it as "a logic bug."

  • Concurrent workflow order bypass (CWOB): a race window lets a terminal action fire before a prerequisite step completes, a pattern OWASP's Business Logic Abuse Top 10 lists as a critical risk, whether the steps span services or sit inside the sub-states of a single request.
  • Object-state manipulation: an attacker overwrites a protected field (role, balance, order status) through a parameter that was never meant to be client-editable.
  • Artifact lifetime problems: one-time tokens, vouchers, or session artifacts get replayed because the server never marked them consumed.
  • Action-limit overrun and shadow functions: rate or quantity caps exist only in the UI, and a hidden or legacy endpoint still accepts the unrestricted action.

TOCTOU (time-of-check to time-of-use) is the mechanical cause behind most race-based variants: the server checks a condition, then acts on it moments later, and an attacker squeezes a second request into that gap.

Real exploit patterns and what they cost

Seeing the exploit sequence makes the abstract categories concrete. Each of these follows a recognizable pattern that a tester can reproduce with a proxy and a stopwatch.

  1. Double-spend on a wallet balance: fire two simultaneous "redeem $50 credit" requests against a server that checks balance, then deducts, without locking the row; both succeed because the check-then-act gap is wide enough for both reads to see the pre-deduction balance.
  2. Admin-by-race during account setup: submit a role-upgrade request twice in parallel during onboarding, before the first write commits, so both requests read "not yet admin" and both get approved.
  3. Coupon stacking: apply the same single-use code to multiple cart sessions opened in parallel tabs, exploiting a validation check that runs before the code is flagged as used.
  4. Hidden-field forging: intercept a checkout request with a proxy tool and rewrite a disabled "price" field the UI never lets you edit, a tampering vector NatProxies covers in detail when explaining why checkout automation and timing-sensitive requests behave unpredictably under manipulation.

A vulnerable pattern typically looks like: read balance, compare to request amount, then write the new balance in a separate step, with no lock held between the read and the write. The impact reaches well beyond a single lost transaction: direct financial loss, exposure under payment and data-protection frameworks like PCI, HIPAA, or SOX, reputational damage once an exploit is publicized, and silent data integrity loss that corrupts downstream reporting and reconciliation.

How to test for logic flaws: manual, concurrent, and semantic methods

Detecting business logic flaws takes a mix of automation and judgment, since no scanner fully understands what a workflow is supposed to prevent.

  • Proxy-based forging: intercept requests and alter hidden, disabled, or client-side-only fields to see whether the server recomputes or blindly trusts them.
  • Direct endpoint calls: skip the UI entirely and call later-stage endpoints to check whether earlier steps are actually enforced server-side.
  • Concurrency testers: fire parallel requests at the same endpoint to probe for race windows, following the integrity and process-timing tests that OWASP's WSTG module enumerates.
  • Unit and integration race tests: write tests that deliberately race requests against the same resource and assert the final state never violates an invariant, such as a balance that goes negative or a coupon redeemed more than once.

Finite-state testing formalizes this: model every allowed transition for a given object (cart, order, account) as a state diagram, then write test cases for every transition that should be disallowed given the current state. This is where recent research adds real value. The SeGa semantic-driven testing approach builds a knowledge base from product requirements and documentation, then generates scenarios with explicit preconditions, detecting significantly more bugs than LLM-based techniques and improving precision noticeably in reported experiments. The underlying insight generalizes well past the tool itself: treating your API docs and requirements as a test oracle surfaces the mismatches between what the system is supposed to do and what the code actually allows.

Pro Tip: Pattern detectors and scanners catch generic anti-patterns like missing auth checks, but workflow-specific invariants (can this refund happen twice, can this role change skip approval) almost always need a human writing scenario-based tests.

Fixing it: state machines, atomic operations, and idempotency

Mitigation work pays off fastest when it targets the architecture rather than patching individual endpoints one at a time.

  • Server-side state machines: persist the authoritative state of every workflow object and validate the current state before allowing any terminal action, never inferring state from the UI.
  • Atomic database operations: use conditional updates (UPDATE ... WHERE balance >= amount), SELECT FOR UPDATE, or SERIALIZABLE isolation for financial or single-use operations. OWASP's race condition guidance recommends pushing atomicity into the database rather than relying on application-level locks, since mutexes don't span multiple server instances and distributed locks like Redis carry split-brain risk during failover.
  • Idempotency keys: attach a unique key to single-use actions (payments, voucher redemption) so a retried or duplicated request is a no-op instead of a repeat.
  • Orchestration and sagas: for workflows that span multiple services, a central orchestrator enforcing ordered transitions closes the CWOB gap that ad hoc service-to-service calls tend to leave open.
  • Revalidate on the server: recompute and check every critical value server-side regardless of what the client submitted, per the OWASP Business Logic Security Cheat Sheet.

A conditional UPDATE statement with a WHERE clause checking the pre-transaction balance turns a check-then-act race into a single atomic operation, closing the exact gap that double-spend attacks rely on.

Document invariants as explicit, testable assertions (balance never negative, voucher redeemed exactly once, role changes require an approval record) and add concurrent-request tests for each one as part of the standard test suite, not as an afterthought during a security review.

How we verify business logic flaws at Earthshaker Security

We run automated scans to flag generic anti-patterns quickly, then hand every workflow-specific finding to a human tester who maps the application's actual state machine and builds abuse-case scenarios by hand, including race conditions and hidden-field forging that scanners alone often miss. Every vulnerability we report gets hand-verified before it reaches a client, which is laid out in our testing methodology.

Findings are written for both technical and non-technical stakeholders, include remediation steps, and include re-testing once a fix ships to confirm issue closure. Internal testing catches some of this, but an external test matters most before a release that touches payment, authorization, or multi-step workflows, where a missed CWOB or state-tampering flaw carries outsized cost.

The overrated fix and the one that actually works

The security industry still treats input validation as the universal answer, and for business logic flaws that advice mostly misses the point. A perfectly sanitized, perfectly typed request can still skip a workflow step or redeem a voucher twice, because the problem was never malformed input, it was a missing check on state. Teams that pour effort into validation libraries while leaving check-then-act gaps in their database layer are solving the wrong problem well.

The overrated fix and the one that actually works — overview diagram

What the research and the taxonomy both point to is less glamorous than a new scanner: model your workflows as explicit state machines, push atomicity into the database, and write concurrency tests as a standard part of the suite, not a pre-audit scramble. The SeGa research reinforces something testers have argued for years, that the biggest detection gains come from treating documentation and requirements as ground truth rather than trusting the code to describe its own intent.

If there is one practical priority for a team with limited time, it is this: pick your three highest-value single-use or financial workflows and verify, today, that the server state transitions for each one cannot be raced or skipped. Everything else on this list matters, but that gap is the one attackers find first.

— caleb

Get a verified assessment of your application's logic

If you want to know whether your checkout, account, or payment workflows hold up under a race or a forged request, that is exactly what a web application penetration test is built to answer, backed by manual verification rather than raw scanner output.

Earthshaker Security

We also test APIs and endpoints directly, since many workflow-order bypasses live in routes the UI never exposes. Check pricing and engagement tiers to find the right scope for your application and get a report with findings your team can act on without a security background.

FAQ

What are logic flaws?

Logic flaws are failures in an application's intended behavior rather than its code syntax, where a legitimate workflow or state transition gets abused to produce an outcome the design never intended. They typically pass standard validation and type checks, which is why scanners alone tend to miss them.

What are the top 10 vulnerabilities?

There is no single universal "top 10" for business logic specifically outside the frameworks that define one; OWASP's Business Logic Abuse Top 10 is the closest standard reference and includes concurrent workflow order bypass as a critical category. The general OWASP Top 10 covers broader web vulnerabilities and is a separate list focused on technical flaws like injection and broken access control.

What exactly is business logic?

Business logic is the set of rules, workflows, and state transitions that define how an application is supposed to behave for a given user or object, such as the order in which a payment must clear before a shipment is created. A business logic flaw occurs when the system lets you reach a state or outcome that breaks one of those intended rules.

What are examples of logic errors?

Common examples include coupon stacking, where a single-use discount code gets applied multiple times through parallel requests, and hidden-field forging, where a disabled price or role field gets edited through a proxy. Race-based examples, like firing two simultaneous withdrawal requests against the same balance, fall into the same category since both exploit valid endpoints in an unintended order or timing.

Sources

Want this run against your app?
Book a scan

Rather have it in your inbox?

We send a note when there is something worth sending. That is a handful of times a year, not a Tuesday newsletter.