Business Logic Flaws

What is a Business Logic Flaw#

A business logic flaw is a vulnerability in the application's intended workflow rather than in its input handling, parsing, or access-control plumbing. The requests look syntactically valid, pass authentication, and contain no injection payloads. The attacker is using the application exactly as designed — just in a sequence, combination, or magnitude the developers never foresaw.

The canonical examples are everywhere: applying a percentage discount after manually setting the cart price to zero, ordering a quantity=-5 item to receive a credit, navigating directly to /checkout/confirm without ever completing payment, and racing 30 concurrent requests against a max_redemptions=1 promo code to drain a $600,000 fee-free transaction window. None of these involve a payload list. Each requires understanding what the application is supposed to do, then doing the opposite.

The taxonomy has matured. The primary classification under MITRE is CWE-840 (Business Logic Errors), with sub-classes for CWE-841 (Improper Enforcement of Behavioral Workflow) and CWE-915 (Mass Assignment / Improperly Controlled Modification of Object Attributes). The OWASP Top 10 historically mapped business logic to A04:2021 Insecure Design; in OWASP Top 10:2025, this category was renumbered to A06:2025 Insecure Design and explicitly named "missing business constraint validation" as a sub-category, closing a documentation gap that previously made the OWASP framing seem limited to architectural drawings rather than runtime rule enforcement.

The biggest taxonomic event of 2025 was the publication of the first dedicated OWASP Top 10 for Business Logic Abuse (BLA) at AppSec Global EU in Barcelona on May 30, 2025, with a refreshed v2 on August 2, 2025. The framework models applications as abstract Turing machines (tape, head, states, transitions) and was validated by LLM-classifying 76,000 CVEs from 2023–2025 plus 25,000 GitHub security issues. The result is the first cross-domain taxonomy that treats business logic not as a category of bug, but as a class of system behaviour that must be reasoned about formally. Categories range from BLA1 Action Limit Overrun through BLA10 Shadow Function Abuse, and they cleanly absorb the older OWASP WSTG-BUSL-01..10 catalogue.

This page is the pillar reference. It defines the class, surveys the six attack variants you must master, summarises the state-of-the-art research from 2024–2026, and links to dedicated deep dives for each variant.

Why Automated Scanners Miss Them#

Traditional dynamic application security testing (DAST) — ZAP, Burp Scanner, Nuclei community templates — achieves close to zero detection on genuine business logic flaws. The structural reason has five components, and they compound:

1. No static signature exists. A negative amount=-1000 is only a vulnerability if the application accepts it and credits the account. Scanning for the parameter name tells you nothing about exploitability. Compare with SQL injection, where ' OR 1=1-- produces a deterministic differential signal.
2. Context is application-specific. Whether POST /api/checkout/confirm without a prior /api/checkout/payment call is a bug depends entirely on the checkout state machine — which a generic scanner cannot model without ingesting the application's intended workflow.
3. Proof requires state verification. Confirming "the negative transfer credited the account" requires reading the balance before and after, in two separate sessions, with the right authentication context. Generic scanners do not track application state across requests.
4. Multi-step workflows. Real exploits often require 3–10 coordinated requests with shared cookies, refreshed CSRF tokens, and ordering constraints. Single-request fuzzing (the model behind every commodity DAST) cannot reproduce them.
5. Race conditions are timing-dependent. A coupon redemption race that works reliably in a lab may fail under network jitter. Reliable detection requires the HTTP/2 single-packet attack (Kettle 2023) — concurrent requests delivered in a single TCP burst, not sequential probes.

A new generation of tools has emerged in 2025–2026 to attack this gap. Pynt, Escape DAST, and StackHawk Business Logic Testing (BLT) — launched on December 16, 2025 — use OpenAPI-driven smart crawling, multi-user role configuration, and feedback-driven test orchestration to detect Broken Object Level Authorization (BOLA) and Broken Function Level Authorization (BFLA) flaws automatically. They do not yet cover price manipulation, race conditions, boundary attacks, or workflow circumvention; those still require either custom YAML rules engines (the BreachVex approach), human pentesters with Burp Repeater + Turbo Intruder, or LLM-assisted specification-guided detection (GPTScan 2024, IRIS arXiv:2405.17238).

Taxonomy — 6 Core Variants#

The six variants below cover the bulk of business logic findings disclosed publicly between 2020 and 2026. Each has a dedicated deep-dive page with attack walkthroughs, real CVEs, code examples, and remediation patterns.

Price Manipulation#

The application accepts a client-supplied price, quantity, total, or currency without re-validating against the server-side product catalog. The attacker intercepts the cart-add or checkout request and substitutes price: 0.01 (or currency: "BTC" against a USD catalog). The server processes the order at the attacker-controlled value. PortSwigger's "Excessive Trust in Client-Side Controls" lab demonstrates this exactly. Real-world cases include CVE-2025-56426 (Bagisto CMS, April 2025, CVSS 8.1, patched in 2.2.3) and HackerOne #614523 (Eternal e-commerce — order amount manipulable via cart submission).

Read the deep dive on Price Manipulation

Negative Quantity Abuse#

A specialisation of price manipulation: the attacker submits quantity: -5 (or a value that wraps via INT32/INT64 overflow, such as 2147483648). If the server multiplies unit_price * quantity without sign validation, the line-item total goes negative and reduces the cart total — sometimes below zero. CVE-2023-45854 (Shopkit 1.0, CVSS 7.5) is the textbook case: the qtd parameter accepted INT32_MAX+1 and wrapped to a negative cart total. HackerOne #364843 (Upserve/OLO) reports the exact same class against a major restaurant ordering platform.

Read the deep dive on Negative Quantity Abuse

Discount Stacking#

Coupons, promo codes, and gift cards are intended for one-time use, but the deduplication logic only checks the immediately previous code (or none at all). Applying coupon A, then coupon B, then coupon A again often re-applies the discount. PortSwigger's "Flawed Enforcement of Business Rules" lab demonstrates the alternating-coupon bypass. Their "Infinite Money" lab demonstrates the gift-card cycle: buy a $10 gift card with a 10% discount → net $9 spent → redeem $10 → profit $1 per cycle, infinitely. HackerOne #59179 (Dropbox) and HackerOne #157996 (Instacart, race-condition variant) are canonical real-world cases.

Read the deep dive on Discount Stacking

Workflow Step Bypass#

A multi-step process — registration, checkout, subscription upgrade, refund — is implemented by exposing each step as its own HTTP endpoint. The attacker calls the final endpoint directly without completing the prerequisites. Classic example: POST /checkout/confirm {order_id: X} from a fresh session. If the server returns HTTP 200 with the order confirmation body, payment was bypassed. HackerOne #271176 (Lyst, 2017) skipped the payment step by crafting checkout_id in a cookie. HackerOne #92481 (Shopify) accessed payment-method addition without prerequisite checkout. The Magento2 PayPal "Bill Me Later" issue (#39145) bypassed checkout entirely via a specific API sequence. This class maps to CWE-841 and OWASP BLA2:2025 Concurrent Workflow Order Bypass (CWOB).

Read the deep dive on Workflow Step Bypass

Limit Override#

The application enforces "one per user" or "max N per day" limits in the application layer (Python check, then database insert) without an atomic guard. Concurrent requests bypass the limit because the check runs before either insert commits. The textbook target is single-use coupons and verification tokens. HackerOne #1717650 (Stripe) — a max_redemptions=1 promotion code redeemed 30 times in parallel, yielding $600,000 in fee-free transactions (payout: $5,000). CVE-2025-31161 (CrushFTP) — race condition in authentication enabling Concurrent Workflow Order Bypass, actively exploited. The class maps to CWE-362 and OWASP BLA1:2025 Action Limit Overrun (ALO).

Read the deep dive on Limit Override

Currency Rounding Abuse#

Less common but high-impact when present: an application performs floating-point arithmetic on currency values (0.1 + 0.2 != 0.3 in IEEE-754), accepts micro-amounts (0.001) that round to zero on display but accumulate in storage, or accepts multiple currencies (USD, BTC, JPY) without canonicalisation. The attacker either drains accumulated rounding error through repeated micro-transactions (Office Space attack), or exploits currency mismatches where prices in USD are charged as the same numeric value in JPY (1/100th the price). The classic discipline rule: never use floating-point for money.

Read the deep dive on Currency Rounding Abuse

State-of-the-Art Attack Techniques (2024-2026)#

The research landscape for business logic exploitation moved faster between 2023 and 2026 than in the entire prior decade. Three streams reshaped the field.

HTTP/2 Single-Packet Attack — James Kettle, Black Hat USA / DEF CON 2023#

In Smashing the State Machine: The True Potential of Web Race Conditions, James Kettle (PortSwigger Research) introduced the single-packet attack: deliver all concurrent requests in a single HTTP/2 frame burst, eliminating network jitter as a confounding variable.

The performance improvement is 4–10x over prior HTTP/1.1 last-byte synchronization. One real-world vulnerability went from "exploitable in 2+ hours" (HTTP/1.1) to "exploitable in 30 seconds" (HTTP/2 single-packet). Concurrent requests now race against the application's internal sub-states — intermediate states that exist only during single-request processing, lasting roughly 1 ms.

In August 2024, researcher @ryotkak published Beyond the Limit: Expanding single-packet race condition with a first sequence sync, which uses IP-layer fragmentation to extend the attack window from the 1,500-byte MTU to the full 65,535-byte TCP window. The result: 10,000 synchronized requests in approximately 166 milliseconds. Implementation: open-source h2spacex (Scapy-based) and Turbo Intruder with engine=Engine.BURP2.

Five Attack Classes from Smashing the State Machine#

Kettle's 2023 paper introduced four entirely new race-condition attack classes beyond the classical limit-overrun:

1. Object Masking — Exploit intermediate states during object creation. The object exists but is not yet fully initialised. A racing request observes the incomplete object and bypasses validation that would fire on the completed version.
2. Multi-endpoint Collisions — Race two different endpoints that touch the same shared resource. Example: POST /transfer racing with GET /balance where both read the same row under different lock semantics.
3. Single-endpoint Collisions — The classical limit-overrun: coupon race, gift card race, vote race.
4. Deferred Collisions — Batch processing vulnerabilities exploitable with time delays, not microseconds. The race window can span hours. Particularly valuable against CDN-fronted applications where simultaneous requests are impossible.
5. Partial Construction Attack — Attack multi-step initialisation of an object before all fields are written.

Listen to the Whispers — Black Hat USA 2024#

Kettle's 2024 follow-up, Listen to the Whispers: Web Timing Attacks That Actually Work, weaponises microsecond-scale timing differentials. Key advances over 2023:

• Hidden attack-surface discovery via timing: response-time analysis detects concealed parameters and HTTP headers that produce no visible response signal — revealing "invisible attack surface" where business logic gates exist but emit no output other than latency.
• Blind injection via timing: detect SQL injection, JSON injection, and parameter pollution where no error message is returned. Timing reveals control-flow divergence (a query scanning 1M rows vs 1 row takes measurably longer, even through a CDN).
• Scoped SSRF discovery: reverse proxies that restrict routing to specific domains are now detectable via timing where pingback-based detection fails entirely.
• Jitter reduction: from 30,000 microseconds (naive HTTP/1.1) down to 200 microseconds (HTTP/2 single-packet) — viable against live production targets without lab conditions.

GraphQL Business Logic Vectors#

GraphQL surfaces unique BL attack vectors that REST-focused detectors miss. 50% of production GraphQL endpoints still accept introspection queries (verified across 2024–2025 surveys), revealing internal mutation names, argument types, and field structures that map directly to business logic flows. Attack categories specific to GraphQL:

• Mutation chaining: multiple mutations in a single payload execute sequentially with shared authentication context. createUser(role: "ADMIN") + grantPermission() may individually pass authorization but together constitute a privilege escalation.
• Exposed admin mutations: deleteUser, resetPassword, generateJWT, modifyRole — frequently missing authorization checks and callable by any authenticated user.
• Field-alias race conditions: GraphQL field aliases let you request the same field multiple times with different arguments in one query. All sub-queries execute server-side in a shared transaction context — an effective race-condition mechanism that doesn't even require HTTP/2.

Real-World Impact#

The selection below mixes the canonical case from each variant with the most actively-exploited 2025 CVEs to illustrate the financial scale.

The financial pattern is consistent: business logic flaws routinely command the highest payouts in bug bounty. Shopify pays $25K–$150K for checkout price manipulation, GitLab $20K–$80K for authorization workflow bypass, and Uber $10K–$50K for pricing logic abuse. The crypto and blockchain sector pays even higher — single business-logic findings against major DeFi protocols have been disclosed at $50K–$500K.

Detection Methodology#

Manual Pentesting#

The professional manual workflow combines four tools:

1. Burp Suite Repeater — establish the baseline request/response, then replay with tampered parameters one at a time. Burp Repeater Groups (2024 update) natively supports the single-packet attack via "Send group in parallel".
2. Turbo Intruder — the canonical tool for HTTP/2 race attacks. Use the race-single-packet-attack.py template with engine=Engine.BURP2, concurrentConnections=1, and gate-based synchronization.
3. h2spacex — open-source Scapy-based library for HTTP/2 last-frame synchronization with the @ryotkak 65535-byte extension. Required when you need 1,000+ synchronized requests for token exhaustion or gift-card mass-redemption.
4. Param Miner (timing-based) — discover hidden parameters and headers that produce no visible response signal but affect server behaviour, revealing business logic gates. Updated in 2024 with timing-based discovery integrated.

The methodology: map the workflow → identify state transitions → tamper one numeric/state parameter at a time → verify state change via a follow-up GET to the appropriate balance/order/account endpoint → escalate to concurrent requests where ordering matters.

Modern Automated Tools (2025-2026)#

The structural limitation across all of them: proof requires application-specific state verification. None of the commodity scanners build a per-finding state_before / state_after evidence dict. Generic 200 OK is not proof — confirmation requires a follow-up GET to the appropriate balance/order/inventory endpoint that demonstrates the tampered value persisted.

BreachVex detects this class via a custom YAML rules engine that encodes per-rule state-check endpoints, a post-tamper probe that compares the resource state before and after the request, and a default-deny proof model that elevates a finding to CONFIRMED only when an actual server-side state change is observed. The default ruleset covers negative transfer, zero-price product, coupon stacking, workflow skip, mass assignment, integer overflow, idempotency reuse, gift-card multiplication, and free-trial reactivation, and is auto-generated from OpenAPI specs at scan time — no human curation required for standard e-commerce or API targets.

Prevention Principles#

The four principles below are the structural fixes that close every variant on this page. Code-level details are in each variant's deep-dive page; the principles themselves are uniform.

Server-Side Authority#

Never trust any value the client submits that affects pricing, quantity, role, status, or workflow state. Always re-fetch the canonical value server-side from the catalog, the user record, or the order state.

# BAD: price comes from the client
@router.post("/cart/add")
async def add_to_cart(item: CartItemInput):
    cart.add(item.product_id, item.quantity, item.price)
 
# GOOD: price fetched server-side from the authoritative catalog
@router.post("/cart/add")
async def add_to_cart(item: CartItemInput):
    product = await catalog.get_product(item.product_id)
    cart.add(item.product_id, item.quantity, product.current_price)

The client is allowed to submit product_id and quantity (with bounds validation). Everything else — price, currency, tax, shipping, role, status — is computed server-side from authoritative storage.

Atomic State Transitions#

Every state-changing operation must run inside a single atomic transaction with explicit row-level locking. The classic mistake is "check then act" without locking the row between the check and the act — the canonical TOCTOU race.

-- BAD: SELECT then UPDATE — race window between the two statements
SELECT redeemed FROM coupons WHERE code = 'SAVE10';  -- returns false
UPDATE coupons SET redeemed = true WHERE code = 'SAVE10';
 
-- GOOD: SELECT FOR UPDATE locks the row for the duration of the transaction
BEGIN;
SELECT redeemed FROM coupons WHERE code = 'SAVE10' FOR UPDATE;
UPDATE coupons SET redeemed = true WHERE code = 'SAVE10' AND redeemed = false;
COMMIT;
 
-- BETTER: single atomic UPDATE that returns the row only on success
UPDATE coupons
SET redeemed_by_order = $1
WHERE code = $2 AND redeemed_by_order IS NULL
RETURNING amount;

The RETURNING form is the cleanest defence: a single statement that succeeds at most once across all concurrent transactions, regardless of how the application code is written.

Idempotency Keys#

Operations that must not double-execute (transfers, charges, order placement) require an idempotency key supplied by the client and stored server-side. Replays of the same key return the cached response instead of re-executing. This is the Stripe API pattern (Idempotency-Key header) and it is the industry-standard defence against duplicate payment, double-refund, and concurrent-submission races.

@router.post("/transfer")
async def transfer(req: TransferRequest, idem_key: str = Header(...)):
    cached = await cache.get(f"idem:{idem_key}")
    if cached:
        return cached  # replay returns cached response
    # execute transfer atomically
    result = await db.execute_transfer(req)
    await cache.set(f"idem:{idem_key}", result, ttl=86400)
    return result

State Machine Enforcement#

Any multi-step workflow — registration, checkout, refund, KYC — must be modeled as an explicit finite state machine with server-side transition validation. The state lives in the database (or Redis), not in the client cookie or hidden form field, and every transition is checked against an allow-list before being applied.

VALID_TRANSITIONS = {
    "cart":     ["shipping"],
    "shipping": ["payment"],
    "payment":  ["confirm"],
    "confirm":  ["complete"],
}
 
@router.post("/checkout/{step}")
async def checkout_step(step: str, session: Session = Depends(get_session)):
    current = await redis.get(f"checkout:{session.id}:state") or "cart"
    if step not in VALID_TRANSITIONS.get(current, []):
        raise HTTPException(400, f"Cannot transition from {current} to {step}")
    # ... process step ...
    await redis.set(f"checkout:{session.id}:state", step)

This is the structural fix for Workflow Step Bypass and SPA Workflow Skip. Direct requests to /checkout/confirm from a fresh session fail at the transition guard — the user has no payment state to advance from.

Resources#

• OWASP Top 10 for Business Logic Abuse (BLA) — First release May 30, 2025
• OWASP Top 10:2025 — A06 Insecure Design
• OWASP WSTG — Business Logic Testing (BUSL-01 to BUSL-10)
• PortSwigger Research — Smashing the State Machine (James Kettle, 2023)