Business logic flaws share no payload signature - they exploit the intended workflow. Confirming abuse requires proving the rule was violated, not detecting an unusual input.
Business logic flaws share no injection payload and no malformed-input signature - they exploit the workflow the application was designed to support, assembled in an order the developer did not anticipate. Confirming one requires proving the rule was violated, not detecting an anomalous byte sequence. That distinction is why pattern matching and anomaly scoring both underperform here: the request looks legitimate right up to the moment the order ships at $0.01.
A price-manipulation POST and a legitimate checkout POST are syntactically identical. Step-skipping looks like a navigation shortcut. A WAF scanning for SQL keywords or shell metacharacters sees nothing, because nothing is malformed. The application accepted the request precisely because it was structurally valid - the flaw is in whether the server enforced the business rule that should have rejected it.
This is the class of bug that only surface in end-to-end DAST coverage of multi-step flows. A scanner that fires single-shot probes at individual endpoints will confirm the payment form accepts input and the confirmation endpoint returns 200, but miss that step 2 is not actually required.
Business logic bugs cluster into a small number of repeating patterns. Each has a distinct confirming artifact - a measurable outcome difference, not a response anomaly - and each requires a tailored probe sequence rather than a single request.
| Pattern | Probe | Confirming artifact | Severity anchor |
|---|---|---|---|
| Price parameter tampering | Submit cart with price field overridden to 0.01 in the POST body | Order confirmed at $0.01 with valid order ID and shipping address | Critical if accepted in production context |
| Workflow step skip | Complete step 1, then POST directly to step 3 without step 2 | Step 3 returns success without any record of step 2 completing | Critical if step 2 is payment or identity verification |
| Coupon or discount limit bypass | Apply coupon code N+1 times; check whether limit is enforced server-side | Each application reduces total; limit not enforced after first use | High - repeat use of a single-use code |
| Negative quantity or balance | Submit order with quantity=-1 or transfer amount=-100 | Cart total becomes negative; refund or credit issued without payment | Critical if resulting credit is redeemable |
# Step 1: add item at its real price - observe cart total POST /cart/add Content-Type: application/json {"item_id": "SKU-9901", "qty": 1} # response: {"total": 199.00, "currency": "USD"} # Step 2: confirm - inject overridden price in the POST body POST /checkout/confirm Content-Type: application/json {"cart_id": "cart_62615533", "price": 0.01, "currency": "USD"} # confirming artifact: 200 OK with order_id present and total: 0.01
The nonce in the cart ID (cart_62615533) scopes the probe to a test transaction so no real order is created in a shared environment. In a staging environment with synthetic accounts the probe is fully safe: the confirming fact is the order record the server returns, not a charge against a real payment instrument.
A 200 is not the proof - the order record is. The confirming artifact must demonstrate that the business rule was actually violated: an order at $0.01 carries a real order ID, a real delivery address, and a real shipping estimate. A step-3 success without a step-2 record in the session means payment was skipped. These are facts about application state, not about HTTP status codes, and they are what the evidence attachment must capture.
Sensitive fields - payment tokens, real order IDs from production - are masked in the evidence. The confirming payload uses a benign nonce in the cart reference so the probe is identifiable and scoped to the test session.
Rating a business logic flaw requires mapping the confirmed outcome to real-world consequence. A price override that produces a $0.01 order is critical if the application processes real payments - the impact is direct financial loss at scale. A workflow skip that bypasses email verification is high; a skip that bypasses payment entirely is critical. Coupon limit bypass is high; negative-quantity credit that is immediately redeemable is critical. The rating is never derived from the cleverness of the manipulation; it follows the confirmed harm.
The probe discipline is the same throughout: a benign nonce scopes the test, a real test account holds any resulting records, no real money changes hands, and the confirming artifact is the application state after the manipulated sequence - an order record, a session without a payment step, a balance after a negative transfer. Pattern matching cannot surface any of this. End-to-end flow coverage, differential comparison of state, and honest severity mapping from confirmed outcome to real impact are the three things that make business logic findings defensible to an engineering team that knows its own codebase.