Business Logic Vulnerabilities
Also known as: Logic flaws · Workflow abuse
Business logic vulnerabilities are flaws in the design of a workflow rather than in the implementation of any single request. Every individual request behaves correctly and passes validation; the flaw is that the sequence, quantity, or context of requests lets an attacker reach a state the designer never intended - completing a checkout without payment, applying a one-time discount repeatedly, or approving your own expense report. Because nothing is technically "broken," these flaws are invisible to signature-based scanners and only surface by reasoning about the flow as a whole.
- CWE
- CWE-840CWE-841
How it works
- 1A multi-step process assumes requests arrive in a fixed order, a fixed quantity, or from a fixed party (a checkout, an approval chain, an invite flow).
- 2The server enforces each individual step's validation but doesn't verify the state or sequence of the process as a whole.
- 3The attacker skips a step, replays one out of order, submits it an unexpected number of times, or supplies unexpected values within otherwise-valid ranges.
- 4The server processes each request as valid in isolation, and the workflow completes in a state the business rule was meant to prevent.
Example
Intended flow: Add to cart -> Apply discount (new customers only) -> Checkout -> Charge card
Abused flow: Apply discount -> Apply discount -> Apply discount -> Checkout
(nothing rejects applying the same one-time discount repeatedly)Impact
Business logic flaws cause direct financial loss (discount and payment abuse), unauthorized approvals, and process-integrity failures - and because they don't trip vulnerability scanners, they often go undetected until the abuse is already at scale.
Remediation
- Model the workflow's valid states explicitly server-side, and reject any request that doesn't match an expected transition - not just each request in isolation.
- Enforce quantity and sequence limits (a discount used once, an approval made by someone other than the requester) at the data layer, not just in the UI flow.
- Add anomaly detection for the abuse patterns themselves - a discount applied unusually often, an approval chain missing a distinct approver.
- Have testing reason about the process end-to-end, not just about individual endpoint validation.
Detection & testing
Walk the workflow out of its intended order, replay individual steps, and vary quantities and actor identity across steps to see whether the server enforces the process as a whole or only validates each request independently.
Impactr finds and proves whether Logic flaws — or flaws like it — are actually reachable in your own web apps and APIs, with a reproducible exploit as evidence.
Tools
Frequently asked questions
Why can't automated scanners find business logic vulnerabilities?
Scanners match traffic against known-bad patterns; a business logic flaw produces no malformed request or error at all - every step is technically valid. Finding it requires understanding what the workflow is supposed to prevent and testing whether that intent is actually enforced, not just whether each request is well-formed.