Business logic vulnerabilities: attacks and testing

Business logic vulnerabilities are flaws in the design or implementation of an application's workflows that let an attacker use legitimate functionality in an unintended way. There is no malformed payload and no injection: every request is syntactically valid and, seen in isolation, looks like normal use of the application. That is why they are the class of vulnerability that best separates a manual pentest from an automated scan, and the reason a scanner can report "no findings" against an application that gives away products, duplicates balances or exposes other users' orders.

This guide explains what a business logic flaw actually is, why SAST and DAST miss it, the classic taxonomy with concrete e-commerce and fintech examples, how the manual test is run following OWASP WSTG, the remediation patterns and why an annual manual pentest is the control that NIS2, DORA and PCI DSS require.

What a business logic vulnerability is

A business logic vulnerability is a flaw in the rules that govern a process, not in the syntax of a request. The application does exactly what the code tells it to, but that code assumes a sequence, a value range or an identity that the attacker does not respect. The canonical example: a shop that trusts the price field sent by the browser and accepts an order with a negative price, generating a credit in the customer's favour.

The difference from a technical vulnerability (SQL injection, XSS, SSRF) is that here there is no signature. There is no malicious string a rules engine can recognise. The "exploit" is a sequence of perfectly formed requests that break a business invariant: a single-use coupon applied three times, another customer's order queried by its identifier, a balance withdrawn twice in parallel.

Why SAST, DAST and scanners miss them

The three AppSec automation layers fail here for the same underlying reason: they do not know your business rules.

• SAST analyses code for dangerous patterns (data flow into a SQL sink, unsafe deserialisation). A logic flaw has no dangerous sink: the code that applies a discount is correct in itself, the problem is that it never checks whether that discount was already consumed.
• DAST fires payloads and looks for anomalies in the response (errors, reflections, timing). A negative price returns 200 OK with a coherent JSON body, so the scanner accepts it as valid. It does not know that a negative price should not exist.
• Vulnerability scanners (Nuclei, Acunetix, Burp Scanner) work from signatures and generic checks. Business logic is unique to each application, so there is no template to reuse.

A telling detail: these flaws almost never receive a CVE, precisely because they belong to a specific application rather than a reusable product. They do not appear in vulnerability databases, which reinforces the point that only a human analyst who understands the process can find them.

Taxonomy of logic flaws with real examples

Price and quantity manipulation

The server trusts values that should be computed server-side. Tampering with price, applying a negative quantity that turns the payment into a deposit, or switching the currency to a lower-value one are variants of the same root cause: data validation lives in the client. It is the most common finding in carts and payment gateways.

Coupon and discount abuse

A single-use coupon that can be reused because it is never marked as consumed, several stackable coupons that were never meant to combine, or the same code applied in parallel before the system invalidates it. In fintech, the equivalent is the welcome bonus claimed several times from chained accounts.

IDOR on orders and resources

When an endpoint like GET /api/orders/1042 returns another customer's order because it lacks object-level authorisation, we are talking about an IDOR or broken access control, the most common flaw class in APIs. Incrementing the identifier is enough to read other people's invoices, addresses or payment data.

Race conditions in transactions

Sending two nearly simultaneous withdrawal or redemption requests can bypass the balance check if the read and the write are not atomic (a classic TOCTOU). It is the mechanism behind double-spending a gift card or exceeding a purchase limit. We cover it in depth in race conditions in web applications.

Mass assignment and role escalation

An endpoint that binds the entire request body to the data model lets you send hidden fields. A PATCH /api/users/me with {"role":"admin"} or {"isVerified":true} in the JSON can grant privileges the interface never exposes. This is API6 in the OWASP API Security Top 10.

Multi-step workflow bypass

Multi-stage processes (cart, shipping, payment, confirmation) assume an order. If you can navigate directly to the confirmation URL without going through payment, or force the order state to "paid" with a parameter, the workflow breaks. It shows up in email-verification sign-ups, KYC flows and checkout.

Insufficient rate limiting (anti-automation)

A six-digit OTP with no attempt limit is trivial brute force. Without rate control, an attacker enumerates gift cards, tests leaked credentials or exhausts password-reset tokens. This is WSTG-BUSL-05 and API4 (unrestricted resource consumption).

How they are tested: OWASP WSTG step by step

The OWASP Web Security Testing Guide (WSTG) devotes section 4.10 to business logic, with nine tests ranging from data validation (WSTG-BUSL-01) to workflow circumvention (WSTG-BUSL-06) and the number of times a function can be used (WSTG-BUSL-05). It is not a scan, it is a hypothesis-driven process:

1. Model the business rules. Before touching the application, the analyst documents the invariants: an order cannot have a negative price, a coupon is used once, a user only sees their own resources. Without this model there are no abuse cases to test.
2. Map the legitimate flow. The full process is walked through with the proxy on (Burp Suite) to capture every request and understand the real state machine.
3. Build the abuse cases. For each invariant a violation is designed: alter the value in Repeater, reorder the steps, replay a request with another user's session, or fire concurrent requests.
4. Test the races. With Turbo Intruder and the single-packet attack (over HTTP/2), nearly simultaneous requests force TOCTOU conditions in payments and redemptions.
5. Verify and document. Each finding comes with a reproducible proof of concept: request, response and exact steps, with CVSS severity justified by business impact.

This work is part of any serious web application penetration test and, when the product exposes services, of the REST and GraphQL API penetration test.

Remediation patterns

The fix almost always consists of moving trust from the client to the server:

• Server-side invariants. Recompute the price from the catalogue, validate that the quantity is greater than or equal to one, and reject any state that is not allowed. The client is never the source of truth.
• Idempotency. Add an idempotency key (an Idempotency-Key header) to payment endpoints so that a resend never charges or credits twice.
• Explicit state machines. Model the flow as an FSM that rejects invalid transitions from the current state (you cannot move to "paid" without passing through "payment authorised").
• Atomic operations. Use database transactions, SELECT ... FOR UPDATE or optimistic locking with a version column to eliminate race conditions.
• Field allow-lists. Bind only the permitted attributes through DTOs, never the whole body to the model, to close off mass assignment.
• Anti-automation. Rate limiting per account and per IP, CAPTCHA on sensitive endpoints, invalidation of single-use tokens and exponential backoff.

Business logic and compliance: why the annual manual pentest is mandatory

Because these flaws depend on each business context, no tool or bug bounty programme covers them reliably: you need an analyst who understands the product's rules. That is exactly the control the current frameworks demand. NIS2 mandates risk management measures with periodic effectiveness testing. DORA imposes threat-led penetration testing (TLPT) on financial entities, where transactional logic is a priority target. PCI DSS 4.0 requires periodic penetration testing of the applications that process payments, an area where price and coupon abuse are the dominant risk. You can see the full mapping in the OWASP Top 10 for businesses.

The practical conclusion: continuous scanning catches the cheap and automatable, but an annual manual pentest, with a retest after every change to authentication, authorisation or payments, is the only exercise that evidences these controls and finds the flaws that actually cost money.

Frequently asked questions

How does a business logic flaw differ from a technical vulnerability?

A technical vulnerability (SQL injection, XSS) has a recognisable signature and is detected by automation. A logic flaw does not: the request is valid and only malicious in the context of a business rule the tool is unaware of. That is why it requires human analysis.

Why does my scanner not find these flaws?

Because scanners look for generic patterns and response anomalies. A negative price or a reused coupon return correct responses (200 OK), with no error or reflection to trigger an alert. The tool does not know your application's invariants.

What tools are used to test business logic?

Mainly Burp Suite (Repeater for manual tampering, Intruder and the Turbo Intruder extension for race conditions with the single-packet attack). Most of the value is in the analyst's judgement, not the tool: you first model the rules and then design the abuse cases.

Are race conditions business logic flaws?

Yes. A race that lets you spend a balance twice or redeem a gift card several times is an abuse of transactional logic. It is mitigated with atomic operations and idempotency. We expand on it in our article on race conditions.

How often should I test business logic?

At least once a year, and always after a significant change to payments, coupons, roles or any multi-step flow. PCI DSS, NIS2 and DORA set that annual cadence for applications that process sensitive data or transactions.