Your WAF blocked 10,000 SQL injection attempts last month. Your scanner found zero critical CVEs. Yet someone just withdrew $50,000 from an account with a $2,000 balance because your deposit confirmation logic had a race condition.
Business logic flaws don't show up in vulnerability scanners. They're not in the OWASP Top 10 as discrete categories. And they're costing organizations millions while security teams focus on traditional attack vectors. The Robinhood 'infinite money glitch' proved this: users exploited the platform's margin calculation logic to generate unlimited buying power, bypassing every perimeter control in place.
Here's why these flaws persist, and why your team keeps missing them.
Myth 1: "Our Scanner Would Find Business Logic Issues"
Reality: Automated scanners detect implementation flaws, not design flaws.
Your DAST tool can find SQL injection because it knows what malicious SQL looks like. It cannot determine whether your refund workflow should allow negative values or whether your discount codes should stack. These are business rules, and scanners have no baseline for what's "correct" versus what's exploitable.
The Robinhood incident illustrated this perfectly. The margin calculation logic worked exactly as coded. No buffer overflows, no injection points. The flaw was in the business rule itself: the system credited deposits immediately while debiting them asynchronously, creating a window for exploitation.
You need threat modeling that maps business workflows, not just attack surfaces. For each critical transaction flow, document: What state transitions are valid? What happens if steps execute out of order? Can values go negative? What's the rollback procedure?
Myth 2: "We'll Catch It in Code Review"
Reality: Developers review code for correctness, not for abuse scenarios.
When your developer reviews a discount code function, they verify it calculates the discount correctly. They don't ask: "What if someone applies this code 47 times in parallel?" or "What if they modify the session variable between validation and application?"
Code review catches bugs. Security review catches exploitation paths. These require different mindsets.
OWASP ASVS v4.0.3 addresses this in Requirement 11.1.2, which calls for business logic verification beyond functional testing. You need someone on the review who thinks like an attacker: "How would I abuse this workflow for financial gain?"
Create abuse case scenarios for every privileged operation. If your app processes payments, refunds, account transfers, or access upgrades, document the "evil user story" alongside the legitimate one.
Myth 3: "Business Logic Testing Is Too Context-Specific to Standardize"
Reality: You can build reusable test patterns for common logic flaw categories.
Yes, every application's business rules are unique. But the exploitation patterns aren't. Race conditions in state machines. Integer overflows in financial calculations. Insufficient workflow validation. Trust boundary violations between client and server.
Build a test library around these patterns:
- Sequence bypass: Can you skip step 2 in a three-step process?
- Parallel execution: What breaks if you submit the same request 100 times simultaneously?
- Boundary manipulation: What happens at zero, negative, maximum integer, or null?
- State confusion: Can you reuse a one-time token or replay a completed transaction?
For PCI DSS v4.0.1 compliance, Requirement 6.4.3 mandates that custom scripts and payment page code undergo security analysis. Business logic review should be part of that analysis for any payment workflow.
Myth 4: "We Don't Need Specialized Testing, Our Pen Test Covers This"
Reality: Annual pen tests give you a snapshot, not continuous business logic validation.
Your pen tester has one week and a defined scope. They'll find the low-hanging fruit: authentication bypasses, obvious injection points, exposed admin panels. They won't map your entire purchase workflow, understand your refund policy nuances, or test every promotional code combination.
Business logic flaws require understanding the application's intended behavior deeply. That's not a one-week engagement. It's ongoing analysis as features change.
Integrate business logic checks into your CI/CD pipeline. When someone modifies the checkout flow, your test suite should verify not just that it works, but that it can't be abused. Write tests that attempt to:
- Purchase items for negative prices
- Apply expired coupons
- Exceed quantity limits through rapid resubmission
- Access other users' order history by manipulating IDs
SOC 2 Type II controls around change management (CC8.1) should include verification that logic changes don't introduce exploitable conditions.
Myth 5: "Our API Gateway Handles Authorization, We're Protected"
Reality: Authorization at the gateway doesn't prevent logic abuse within authorized operations.
Your API gateway confirms the user is authenticated and has permission to call /api/transfer. Great. It doesn't validate whether transferring -$5,000 makes business sense, or whether the destination account should accept transfers from this source.
Gateway-level authorization is necessary but insufficient. You need business logic authorization: Does this operation make sense given the current state, the user's history, and your business rules?
Consider a funds transfer endpoint. Gateway checks: Is the user logged in? Does their role allow transfers? Business logic must check: Does the source account have sufficient funds? Is the destination account valid? Has this user exceeded their daily transfer limit? Is this transfer pattern consistent with their history?
For NIST 800-53 Rev 5 control AC-3 (Access Enforcement), you need to enforce both technical access controls and business rule constraints.
What to Do Instead
Stop treating business logic flaws as edge cases. They're systematic risks that require systematic detection.
First, map your critical business workflows. For each workflow that involves money, access privileges, or sensitive data, document the state machine: valid states, valid transitions, rollback procedures.
Second, build abuse cases for each workflow. Have someone who wasn't involved in building the feature try to break it. Pay particular attention to operations that can be repeated, combined, or executed out of sequence.
Third, implement server-side validation for all business rules. Never trust client-side calculations, especially for prices, quantities, or eligibility. Recalculate everything server-side using authoritative data.
Fourth, add business logic test cases to your automated test suite. These should fail if someone changes the discount calculation logic or removes a balance check.
Finally, conduct business logic threat modeling for major releases. Before you ship the new promotional code system or the updated refund workflow, have your security team review it specifically for logic flaws.
Your scanner won't find these issues. Your WAF won't block them. You need humans who understand both your business rules and how attackers think. The Robinhood incident proved that even well-funded engineering teams miss these flaws. Don't wait for your own "infinite money glitch" to make business logic review a priority.
