Description
Business logic bypass vulnerabilities (CWE-840 — Business Logic Errors) are flaws in the design or implementation of application workflows rather than in technical security controls. Unlike SQL injection or XSS, these vulnerabilities exploit the application behaving exactly as coded — but the code fails to enforce the intended real-world business rules. As a result, standard automated scanners almost never detect them; they require a human tester who understands the application's intended purpose.
The OWASP Top 10 classifies these under A04:2021 — Insecure Design, reflecting that the vulnerability class stems from design decisions rather than implementation bugs. Examples include: applying a discount coupon multiple times to a single order, skipping a mandatory payment step in a multi-step checkout flow, purchasing a negative-quantity item to receive a credit, transferring funds beyond an account balance, or re-using a single-use token. Each of these exploits valid application functionality in a sequence or manner the developer did not anticipate.
Business logic flaws tend to be high-impact because they often directly translate to financial loss, fraud enablement, or regulatory violations. They are also highly application-specific, meaning there is no generic fix — each flaw requires a targeted design correction.
How It Works
Multi-step flow bypass: An e-commerce checkout requires three steps: cart → payment → confirmation. The payment step's HTTP request is:
POST /api/checkout/payment HTTP/1.1
Host: shop.example.com
Authorization: Bearer <user_token>
{ "orderId": "ord_123", "paymentMethod": "card", "token": "tok_visa" }
The attacker intercepts the flow with Burp Suite and discovers that submitting directly to /api/checkout/confirm with a valid orderId skips the payment step entirely — the server confirms the order without verifying that payment was collected.
Price manipulation: A mobile app computes the total client-side and sends it with the order:
{ "items": [{"id": "item_99", "qty": 2}], "total": 0.01 }
If the server trusts the client-supplied total field rather than recomputing it from the item catalog, the attacker purchases items for a penny.
Negative quantity: Some applications fail to validate that quantities are positive:
{ "cartAction": "add", "itemId": "item_99", "qty": -5 }
Adding -5 of a $20 item subtracts $100 from the order total, potentially making the entire order free or generating a store credit.
Coupon replay: A coupon code is marked as used only after the order completes. If the attacker can initiate multiple parallel requests before any of them complete, all requests pass the "is coupon used?" check before any has been marked used — a classic time-of-check/time-of-use (TOCTOU) race.
Impact
- Financial fraud — free or discounted goods, fraudulent refunds, account balance manipulation.
- Feature abuse — accessing premium features without payment by replaying authorization steps.
- Loyalty/reward manipulation — earning points, credits, or referral bonuses repeatedly through replay or parameter tampering.
- Workflow bypass — skipping mandatory approval steps, KYC verification, or age checks.
- Data integrity — corrupting order records, inventory counts, or audit trails through unexpected state transitions.
- Regulatory exposure — bypassing identity verification or consent steps that are legally required.
Detection
- Map every multi-step workflow and test each step in isolation — attempt to skip, reorder, or repeat steps using Burp Suite. Specifically test whether step N+1 validates that step N was completed.
- Manipulate numeric values in all requests — prices, quantities, discounts, balances, and limits. Test zero, negative, and extremely large values.
- Replay single-use tokens and actions — password reset links, email verification tokens, discount codes, and one-time offers. Attempt to use each multiple times and across different accounts.
- Test parallel request races — use Burp Suite's Turbo Intruder or the Last-Byte Sync technique to send simultaneous requests that target the same resource. Look for double-spend or double-apply scenarios.
- Review state transitions — identify all states an object can be in (e.g., order: pending → paid → shipped → refunded) and attempt invalid transitions (e.g., refunding a pending order, shipping an unpaid order).
- Check client-side trust — search the JavaScript bundle and mobile app for any business logic computed client-side (totals, discounts, eligibility checks). If the server accepts the client's computed value, test manipulation.
Remediation
Compute and validate all business-critical values server-side. Never trust client-supplied prices, totals, discounts, or eligibility flags. Recompute them from authoritative data sources (product catalog, user account state) on every request.
Enforce workflow sequencing. Use server-side session or database state to track which workflow steps have been completed. Before processing step N, verify step N-1 is recorded as complete.
Validate all numeric inputs. Apply minimum, maximum, and type constraints to all numeric fields — reject zero, negative, and out-of-range values at the API layer before any business logic runs.
Use atomic database operations. For operations that involve a check followed by an update (check coupon is unused, then mark it used), use database transactions with appropriate isolation levels or conditional update queries (UPDATE coupons SET used=1 WHERE id=? AND used=0).
Conduct dedicated business logic testing. Standard DAST tools cannot find these flaws. Allocate time during penetration testing specifically for manual workflow analysis by testers who understand the application's business domain.