What are business logic vulnerabilities?
A business logic vulnerability is a flaw in how an application enforces its own rules, letting someone misuse valid features to reach an outcome the business never intended. That matters because there is no injected payload and nothing crashes, yet the results are very real: a double refund, an order shipped without payment, or one customer quietly reading another customer's data. You will also see these called application logic flaws, or simply logic flaws. (OWASP) describes them as ways of using an application's legitimate processing flow to produce a negative consequence.
The tricky part is that the code often does exactly what it was told to do. The gap sits between the developer's assumptions and how a determined user actually behaves. When a rule that should exist was never written down, the application happily follows the path an attacker lays out for it.
Secure Coding Cheat Sheet
Build server-side validation and safe workflows into your code from the start.
Why business logic vulnerabilities happen
Most logic flaws trace back to assumptions that felt safe at the time. A developer assumes nobody will send a negative quantity, request a page out of order, or run the same action twice in the same second. Those assumptions rarely get written into the code as explicit checks, so the rule only lives in someone's head.
Complexity makes this worse. In a large system, no single engineer fully understands every path a request can take, and undocumented invariants get lost between teams. Trusting client-side validation adds another gap, since anything the browser enforces can be replayed or edited before it reaches the server.
The pace of development is now part of the story too. AI copilots and machine-speed release cycles produce far more code than any team can review line by line, which raises the odds that a business rule goes unenforced somewhere in the flow. Wiz research in the State of SDLC 2026 report found that AI-generated defaults tend to repeat the same weakness across many projects rather than causing isolated mistakes. More code paths mean more places for a quiet assumption to become an exploitable gap.
Common types of business logic vulnerabilities
Logic flaws show up in a handful of recurring shapes, many of which MITRE catalogs in its CWE-840 business logic errors category. The table below pairs each common type with a concrete example of how someone abuses it in practice.
| Type | How it gets abused (example) |
|---|---|
| Price manipulation | Checkout accepts a negative quantity, so the cart total drops and the shopper effectively gets paid to buy. |
| Workflow or step bypass | A user jumps straight to the order-confirmation endpoint and receives goods without ever completing payment. |
| Privilege escalation | Changing a role value in a request from "user" to "admin" unlocks actions meant only for staff. |
| Broken object level authorization (BOLA) | Swapping an account ID in an API call returns a different customer's records. |
| Coupon or refund abuse | The same discount code applies repeatedly, or a refund fires before the returned item is ever verified. |
| Race conditions | Two requests sent at the same instant redeem one gift-card balance twice. |
| State-transition flaws | An account moves from "unpaid" straight to "fulfilled" without ever passing through "paid." |
| Trusting client-side controls | The browser hides a button, but the underlying endpoint still accepts the blocked request. |
Why scanners miss business logic flaws
Automated tools are good at spotting things that have a recognizable shape. Static application security testing (SAST) reads source code and matches patterns that tend to be dangerous, like unsanitized input flowing into a query. Dynamic application security testing (DAST) pokes a running app with malformed requests and watches for known failure signatures.
A missing rule has no shape for either tool to match. There is no bad function call to highlight and no malformed input to send, because every request looks perfectly valid on its own. The problem is only visible when you understand what the application was supposed to prevent, which is intent, not syntax or data flow.
Humans have that context, but context alone does not scale. A reviewer who knows the business rules still cannot read millions of lines across every service and every release. That gap between what people understand and what they can physically check is exactly where logic flaws survive.
Watch 5-min demo
See how code-to-cloud context surfaces the risks that actually matter.
The business impact of logic flaws
Because these flaws ride on real features, their impact tends to be direct and financial. Fraud is the most common outcome: refunds that should not fire, purchases that cost nothing, and balances that multiply. Picture a transfer endpoint that accepts a negative amount, so sending "minus 500" from an attacker's account actually credits it.
The damage rarely stops at money. Broken authorization exposes sensitive data across accounts, privilege escalation opens the door to account takeover, and each new abuse path widens the attack surface an attacker can chain together. One weak rule often becomes the first step in a much larger incident.
How to detect business logic vulnerabilities
You cannot scan your way to these flaws, so detection is a deliberate, hands-on process. The steps below move from understanding your rules to actively trying to break them.
Map your intended business rules, so you have a written baseline of what should never be allowed to happen.
Map every entry point, including APIs, background jobs, and mobile clients, not just the main web flow.
Test authorization and ownership with two accounts, checking whether one user can act on another user's objects.
Test state transitions by skipping, repeating, and reversing steps in each workflow.
Test values and limits with negatives, duplicates, and concurrent requests to see how the app handles the unexpected.
Compare code paths across web, mobile, and background processing, since a rule enforced in one is often missing in another.
Combine controls: threat modeling, code review, SAST, DAST, and manual abuse testing each catch what the others miss.
In practice, the two-account authorization test alone surfaces a surprising number of BOLA issues, because ownership checks are the rule teams forget most often.
How to prevent business logic vulnerabilities
Prevention works best when the rules live in the code, not just in someone's memory. Strong code security practices make correct behavior the default and catch bad assumptions before they ship.
Validate everything server-side: never trust prices, quantities, or permissions that arrive from the client.
Enforce least privilege: give each user and service the narrowest access the task requires.
Apply defense-in-depth: layer checks so one missed rule does not become a clear path in.
Track transaction state on the server: decide what "paid" or "shipped" means in one trusted place, not in the browser.
Threat-model every user journey during design: ask what a hostile user could do at each step before it is built.
Add abuse-case tests to QA: write tests that try to skip steps, replay actions, and send impossible values.
Shift left with guardrails in the pipeline: block risky changes in the IDE and CI/CD before they reach production.
That last point is where prevention pays off at scale. Blocking risky changes in the pipeline lets teams fix systemic issues early instead of chasing one-off problems once they reach production.
Reading code intent to catch business logic flaws
Pattern-based scanning struggles with logic flaws because a missing business rule leaves nothing to match. Wiz AI-SAST takes a different route by reading your code in context and reasoning about what each workflow is meant to allow, questioning logic issues like skipped payments or client-side trust boundaries rather than only flagging risky syntax.
To cut false positives, those findings become context for the Red Agent, which actively attempts to exploit the weakness in your live cloud environment and proves the risk with evidence. That intelligence is enriched by the Wiz Security Graph, which instantly prioritizes toxic combinations like a logic flaw in an internet-exposed workload that can reach sensitive data.
Once a risk is verified, the Green Agent investigates the root cause, generates tailored remediation code, and routes the fix directly to the developer who owns it. The view behind it stays simple: at machine speed, context is what proves which risks are real. Get a demo to see how Wiz AI-SAST surfaces the logic risks that matter.
Uncover your real logic risks
See how Wiz connects code, cloud, and runtime to prioritize exploitable risk.
