TL;DR
- ✓Business logic vulnerabilities are flaws in how an application's rules and workflows are enforced, where every individual request is technically valid but the sequence or values break intended behavior.
- ✓Payment tampering is the highest-impact subclass: manipulating price, quantity, currency, or discount fields to pay less than intended or nothing at all.
- ✓Automated scanners almost never find these because there is no malformed payload or injection signature, only legitimate requests used in unintended ways.
- ✓They are tested under the WSTG Business Logic category (WSTG-BUSL) and require manual reasoning about the application's workflows.
- ✓Common patterns include negative quantities, client-side price trust, coupon stacking, race conditions on balance checks, and skipping workflow steps.
Business logic vulnerabilities are the flaws that scanners walk right past, because nothing about the request is malformed. There is no quote to break out of, no script tag, no payload signature. The application processes a perfectly valid request that simply should not have been allowed given its workflow, like checking out with a negative quantity or applying the same coupon a hundred times.
Payment tampering is the subclass with the most direct financial impact, and it is everywhere in e-commerce and SaaS billing. This post covers the common patterns, how to test for them by reasoning about workflows rather than fuzzing inputs, and the controls that prevent them. They live in the WSTG Business Logic category (WSTG-BUSL).
What are business logic vulnerabilities?
Business logic vulnerabilities are weaknesses in the design and enforcement of an application's rules, where an attacker abuses legitimate functionality in a way the developers never intended. Unlike injection or XSS, there is no technically invalid input; the request is well-formed, authenticated, and authorized, but the outcome violates a business rule, like getting a product for free or escalating a workflow past a required approval.
Because they depend on understanding what the application is supposed to do, they cannot be found by pattern matching. You have to model the intended flow (cart, checkout, payment, fulfillment) and then ask what happens when you take steps out of order, supply boundary values, or repeat an action. This is why they are a manual-testing staple in our web app test cases.
Strobes insight
Automated scanners find roughly zero business logic flaws. There's no malformed payload to flag, just valid requests used wrong. These bugs need a human (or a reasoning agent) who understands what the app is supposed to do.
How does payment tampering work?
Payment tampering works by manipulating values in the purchase flow (price, quantity, currency, discount, or the final amount) that the server trusts instead of recomputing. The classic case is an application that sends the item price to the client and reads it back at checkout, letting you edit it in Burp Suite.
# Trusting a client-supplied price
POST /cart/checkout
{"item_id": 42, "price": 1499.00, "qty": 1}
# Tampered: pay one cent
{"item_id": 42, "price": 0.01, "qty": 1}
# Negative quantity to create a credit
{"item_id": 42, "price": 1499.00, "qty": -3}
# Currency swap: pay 100 IDR instead of 100 USD
{"item_id": 42, "amount": 100, "currency": "IDR"}
Other variants include integer overflow on quantity, rounding abuse on per-unit discounts, and tampering with the success callback from a payment gateway so the app marks an order paid without the gateway confirming. Always intercept and modify; never assume a field is server-validated.
What are common business logic attack patterns?
Most business logic findings fall into a handful of recognizable patterns, which gives you a checklist to work through on any transactional app. The trick is testing the workflow, not the field.
- Negative or zero values: negative quantity for a refund, zero-price items, or negative funds transfers.
- Coupon and discount abuse: stacking multiple codes, reusing single-use codes, or applying a percentage discount more than once.
- Race conditions: firing parallel requests to redeem one gift card balance twice, or withdraw before a balance check completes (a time-of-check to time-of-use flaw).
- Workflow bypass: jumping straight to the confirmation step to skip payment, or reaching fulfillment without approval.
- Quantity and limit evasion: exceeding per-account purchase caps by changing IDs or splitting requests.
For payment race conditions specifically, Burp Suite's Turbo Intruder and the single-packet attack technique are the tools of choice.
Business Logic Test Patterns
Value tampering
- ✓Negative / zero quantity
- ✓Client-supplied price
- ✓Currency swap
- ✓Integer overflow on totals
Workflow abuse
- ✓Skip a required step
- ✓Replay single-use coupons
- ✓Reorder checkout steps
- ✓Bypass approval gates
Timing
- ✓Race on balance deduction
- ✓Double-redeem gift cards
- ✓TOCTOU on limits
- ✓Parallel coupon apply
How do you test for business logic flaws?
Test business logic by first mapping the intended workflow in full, then deliberately violating each assumption it makes about order, values, and repetition. This is reasoning work, not fuzzing, so it starts with understanding the feature: what are the steps, what does each one assume the previous one guaranteed, and where is a value taken on trust.
Work through the app with Burp Suite in front of you and ask: can I skip a step (go to /checkout/confirm directly), repeat a step (replay a coupon), reorder steps, supply a boundary or negative value, or change an ID to act on someone else's object. Run timing-sensitive flows (balance deductions, one-time tokens) through Turbo Intruder to test for race conditions. This kind of multi-step reasoning across an entire application is exactly where AI-driven, continuous testing shines, which is the core premise of agentic pentesting.
How do you prevent business logic and payment tampering?
Prevent these flaws by enforcing every rule server-side and never trusting client-supplied values that have financial or authorization meaning. For payments, look up prices, taxes, and discounts on the server from the catalog and recompute totals; never accept a price, amount, or currency from the request body as authoritative.
Beyond that: validate quantity ranges (reject negatives and absurd values), enforce single-use tokens and coupons with server-side state, use atomic transactions and locking to close race conditions, verify each workflow step's prerequisites server-side rather than trusting the client reached it legitimately, and confirm payment status by querying the gateway directly instead of trusting a client redirect. These controls map to the broader access-control and verification themes in the OWASP Top 10.
Frequently asked questions
What is a business logic vulnerability?
A business logic vulnerability is a flaw in how an application enforces its intended rules and workflows. The attacker uses entirely valid, authenticated requests, but in an order or with values the design did not anticipate, producing outcomes like free purchases or skipped approvals. There is no malformed input to detect.
Why can't scanners find business logic flaws?
Automated scanners detect known patterns such as injection strings or malformed payloads. Business logic flaws use legitimate, well-formed requests, so there is no signature to match. Finding them requires understanding what the application is supposed to do and reasoning about how to violate that intent, which is manual or AI-reasoning work.
What is payment tampering?
Payment tampering is manipulating values in a purchase flow, such as price, quantity, currency, or discount, that the server trusts instead of recomputing. Examples include editing a client-supplied price to one cent, submitting a negative quantity, or swapping the currency to a cheaper one. Server-side recomputation prevents it.
Where do business logic flaws fit in OWASP?
They are covered by the Business Logic Testing category (WSTG-BUSL) in the OWASP Web Security Testing Guide and overlap heavily with A01:2021 Broken Access Control in the OWASP Top 10 when the abuse crosses authorization boundaries. The 2021 list also introduced A04 Insecure Design, which captures many logic weaknesses.
How do you test for race conditions in payment flows?
Send multiple concurrent requests to a state-changing action, like redeeming a gift card or deducting a balance, so they hit the server before the first one finishes updating state. Burp Suite's Turbo Intruder and single-packet attack are the standard tools for landing these requests close enough together to win the race.
How do you prevent payment tampering?
Enforce all pricing server-side: look up prices and discounts from the catalog, recompute totals, and never trust a price, amount, or currency sent by the client. Validate quantity ranges, use atomic transactions to stop race conditions, and confirm payment by querying the gateway directly rather than trusting a client redirect.
Sources and references
L
Likhil Chekuri
Application Security Engineer, Strobes
Likhil Chekuri is an AppSec engineer at Strobes who has run hundreds of web, mobile, and cloud penetration tests for regulated industries.
