A business logic vulnerability isn't a bug in your code's syntax -- it's a bug in your product's rules. In 2015, security researcher Egor Homakov showed that Starbucks' gift card platform let him transfer balance between two cards he controlled faster than the backend could reconcile the totals, effectively duplicating money through a race condition. That same year, a researcher on HackerOne found that Shopify's checkout accepted negative order quantities, turning a "return" into same-transaction store credit. Neither exploit touched a database query or injected a script tag. Both abused the application doing exactly what its code told it to do, just not what the business intended it to allow. Because these flaws pass every technical security scan, they are the vulnerability class most likely to slip past automated tooling and straight into production, sometimes for years.
What Is a Business Logic Vulnerability?
A business logic vulnerability is a design or implementation flaw that lets an attacker abuse an application's intended workflow to produce an outcome the business never sanctioned, without breaking a technical control such as input validation, authentication, or access control. MITRE catalogs this class under CWE-840 ("Business Logic Errors"), a parent category for weaknesses that exist not because a developer mishandled a string, but because the sequence of allowed actions itself contains a gap. A checkout flow that lets a coupon be applied twice, a loan application that lets an applicant edit their income after the credit check runs, or an API that lets a "cancel order" request arrive after the "ship order" request has already fired are all technically valid requests processed by technically correct code. The vulnerability lives in the workflow, not the syntax.
How Is a Business Logic Vulnerability Different From a Technical Vulnerability Like SQL Injection?
The difference is that SQL injection breaks a technical control -- input sanitization -- while a business logic vulnerability breaks an assumption about the order and context in which a legitimate user is supposed to move through a workflow. A SAST tool can flag "SELECT * FROM users WHERE id = " + userInput because that string-concatenation pattern is a known signature; there is no equivalent signature for "this API allows a refund request to be submitted before the corresponding purchase request completes." OWASP formalized this gap in the API Security Top 10 2023 list with category API6:2023, "Unrestricted Access to Sensitive Business Flows," specifically because traditional scanners were missing it. A request to abuse a promo-code endpoint looks, byte for byte, identical to a legitimate request to redeem a promo code -- the only thing that differs is intent and sequence, which static and dynamic scanners have no model for.
What Are the Most Common Types of Business Logic Vulnerabilities?
The most common types fall into five recurring patterns: race conditions, workflow step-skipping, parameter and price manipulation, unrestricted access to sensitive flows, and privilege-transition abuse. Race conditions exploit the gap between a balance check and a balance update, as in the 2015 Starbucks case, where near-simultaneous requests beat the reconciliation logic. Workflow step-skipping calls a later-stage API endpoint directly, bypassing an earlier verification step the UI would normally enforce -- for example, hitting a /complete-kyc endpoint without ever submitting the identity document it depends on. Parameter and price manipulation covers cases like Shopify's 2015 negative-quantity bug, where a client-controlled field the server trusted (quantity) was never bounded server-side. Unrestricted access to sensitive flows, OWASP's API6:2023, is the absence of rate limiting or anomaly detection on flows like account creation, password reset, or coupon redemption, allowing automated abuse at scale. Privilege-transition abuse exploits gaps in state machines, such as an approval workflow that lets a requester also act as their own approver if two API calls are timed to overlap.
What Are Real-World Examples of Business Logic Vulnerabilities?
Four well-documented incidents show the range of business logic vulnerabilities in production systems: Starbucks' 2015 gift-card race condition, Shopify's 2015 negative-quantity checkout bug, the DAO's 2016 reentrancy exploit, and Parler's 2021 predictable-ID data exposure. In the DAO case, an attacker drained roughly $60 million in ether by exploiting the order of operations in the "split" function: the smart contract sent funds to an external address before updating the sender's internal balance, so a recursive call back into the withdrawal function could repeat the transfer before the balance ever decremented. It was not a cryptographic flaw or a compiler bug -- it was a business logic error in the sequence of "pay, then record" instead of "record, then pay." Separately, Parler's January 2021 data exposure of roughly 70 terabytes of user content stemmed in part from sequential, predictable post and media identifiers that let researchers script a complete crawl of "private" content through an otherwise legitimate viewing flow with no volumetric abuse controls in place. None of these four systems had a missing authentication check; each had a workflow assumption that didn't hold under adversarial use.
How Do You Detect Business Logic Vulnerabilities?
You detect business logic vulnerabilities primarily through manual abuse-case testing and workflow threat modeling, not automated scanning, because SAST and DAST tools evaluate code patterns and traffic signatures rather than intent. The OWASP Testing Guide dedicates its section 4.10 to business logic testing and enumerates nine specific test types, including testing for the ability to bypass business process flow, testing for defenses against application misuse, and testing for process-timing race conditions. In practice this means mapping every state machine in the product -- order status, KYC status, subscription status -- and then deliberately attempting to move an entity between non-adjacent states: cancel after ship, refund before purchase confirms, downgrade a plan mid-billing-cycle to dodge a proration charge. Race conditions specifically require sending concurrent, near-simultaneous requests (tools like Burp Suite's Turbo Intruder are built for this) because a sequential test suite run one request at a time will never observe the timing gap an attacker exploits.
How Do You Prevent Business Logic Vulnerabilities?
You prevent business logic vulnerabilities by enforcing server-side state and sequence validation at every step of a workflow, not just at its edges. That means recalculating price, quantity, and eligibility server-side rather than trusting client-submitted values, wrapping balance-affecting operations in atomic database transactions or row-level locks so two concurrent requests cannot both read a stale balance, and applying rate limiting and anomaly detection to sensitive flows as OWASP's API6:2023 recommends -- account creation, coupon redemption, and password reset chief among them. Idempotency keys close the specific gap that let the DAO's reentrancy attack repeat a transfer, by ensuring a given operation can only execute once regardless of how many times it's invoked. Because these flaws originate in design, not code, the highest-leverage prevention step is threat-modeling the state machine before the first line of the workflow is written, so the "cancel after ship" or "refund before purchase" case is closed by design rather than discovered by an attacker.
How Safeguard Helps
Business logic vulnerabilities rarely show up in a dependency scan on their own, but they become far more dangerous when a vulnerable library sits directly inside a sensitive workflow an attacker can already manipulate. Safeguard's reachability analysis traces whether a vulnerable function surfaced in your SBOM is actually invoked by the code paths implementing flows like checkout, refund, or account transfer, so security teams can prioritize the intersection of exploitable code and exposed business logic instead of triaging every CVE in a manifest equally. Griffin AI reviews pull requests for the state-and-sequence assumptions that unit tests typically miss, flagging workflow branches where a step can be skipped, replayed, or reordered by a malicious client. Safeguard generates and ingests SBOMs continuously across services so that reachability context stays accurate as workflows evolve, and where a fix is a scoped code change rather than a design decision, Safeguard opens an auto-fix PR so engineers spend their review time on the logic itself rather than on writing the patch from scratch.