OpenAPI changed how teams think about API contracts. You write the spec, you generate the documentation, you validate requests against the schema, and you have a shared, machine-readable agreement about what your API accepts and what it returns. The tooling ecosystem around OpenAPI is genuinely excellent. Schema validation, code generation, contract testing, mock servers these are real productivity gains.
They catch a specific category of problem: requests that are structurally wrong. A missing required field. A value with the wrong type. A string where an integer was expected. A response that does not match the declared schema.
They cannot catch requests that are structurally correct but semantically wrong. A request that supplies every required field with the correct types, passes every schema validation rule, and produces a response that conforms to the declared schema but that exploits a gap in the business rules the API was supposed to enforce.
This is the category of vulnerability that schema validation was never designed to detect. Business logic flaws are not schema violations. They are cases where the API accepts exactly what the spec says it should accept and produces exactly what the spec says it should produce, but the business outcome is something that should never have been allowed to occur.
Three categories of business logic flaws appear more consistently than any others in API security assessments: price manipulation, workflow state skipping, and quantity and limit abuse. Each has a different mechanism. All three share the same fundamental cause: the API enforces the shape of the data without enforcing the rules that govern what the data is allowed to mean.
Category One: Price Manipulation
The Core Pattern
Price manipulation flaws occur when an API accepts a price, discount, total, or other monetary value as client-supplied input and uses that value in a financial calculation without recalculating it from authoritative server-side data.
The vulnerability is in the trust. The server receives a price value, trusts that it is correct, and processes the transaction at that price even though the price was provided by the entity with the most incentive to manipulate it.
The Minimal Example
An e-commerce checkout API accepts a cart submission:
The OpenAPI spec for this endpoint defines unit_price as a number, quantity as an integer, and total as a number. The schema is perfectly valid. A request with unit_price: 0.01 and total: 0.02 also passes schema validation both values are numbers, both are positive, both conform to the declared types.
If the server processes the transaction at the client-supplied price, a product that costs $29.99 can be purchased for $0.01. Not because of a vulnerability in the payment system. Because the API trusted the client to tell it what the price was.
The correct implementation: the server looks up the price of PRD-1847 from the product database when it receives the checkout request. The client-supplied unit_price is ignored, or validated against the server-side value and rejected if it differs. The total is calculated by the server, not supplied by the client. The client supplies what the user chose to buy. The server determines what that choice costs.
Variants Worth Testing
Discount field manipulation. APIs that accept a discount amount or percentage as client input without validating it against an entitlement (is this user allowed this discount?) or against a maximum (is this discount amount within the allowed range?). Submitting discount_percent: 100 or discount_amount: 9999 against endpoints that accept these as inputs.
Negative price submission. Some payment processing APIs, when they receive a negative total, attempt to process a refund rather than a charge. Submitting a negative total or unit_price can transform a purchase into a refund.
Currency manipulation. APIs that accept a currency parameter and apply exchange rates server-side may be vulnerable if the exchange rate lookup is not validated against the transaction's actual currency. Submitting a high-value currency code with a low-value-currency amount can manipulate the charged total.
Shipping cost manipulation. APIs that accept a shipping cost as client input, or that allow the user to select a shipping option and specify its cost, can be manipulated to set shipping to zero or to a negative value.
Category Two: Workflow State Skipping
The Core Pattern
Workflow state skipping flaws occur when a multi-step process is enforced by client-side state rather than server-side state. The server accepts a request for step N without verifying that steps 1 through N-1 were legitimately completed.
The vulnerability is in the assumption. The server assumes that if a request for step 3 arrives, step 2 must have completed correctly because the frontend would not have sent the step 3 request without completing step 2. This assumption is wrong. The attacker does not use the frontend.
The Minimal Example
A SaaS onboarding flow has three steps:
- Accept terms of service
- Complete payment setup
- Activate account
Each step has a corresponding API endpoint:
POST /api/onboarding/accept-terms
POST /api/onboarding/setup-payment
POST /api/onboarding/activate-account
The activate-account endpoint creates a fully active account and provisions access to paid features. The business logic requires that payment setup must be completed before account activation.
The vulnerability: the activate-account endpoint validates only that the user is authenticated it does not verify that the setup-payment endpoint was successfully called and completed for this account. An attacker can skip step 2 and call activate-account directly, obtaining a fully active paid account without completing payment setup.
The OpenAPI spec for activate-account defines a request body that matches the authenticated user context. Schema validation passes. The workflow state that should have been checked "has this user completed payment setup?" is not part of the schema. It is a semantic constraint that the spec cannot represent and that schema validation cannot enforce.
Variants Worth Testing
Payment bypass in e-commerce. Multi-step checkout flows where the final order confirmation endpoint does not verify that payment was successfully processed before confirming the order. Submitting the order confirmation request with a payment_id that belongs to a different transaction, or with a payment_id that was never successfully charged.
Identity verification bypass. KYC flows where the document verification step can be bypassed by calling the "verification complete" endpoint directly. The endpoint validates that the user is authenticated; it does not validate that the verification documents were reviewed and approved.
Approval workflow bypass. Multi-stage approval workflows (purchase approvals, content moderation, access grants) where the final approval endpoint does not verify that each required approval stage was completed. Submitting the final approval request directly, skipping intermediate stages.
Subscription upgrade without payment. Trial-to-paid upgrade flows where the account upgrade endpoint does not verify that a payment method was successfully charged before upgrading the account tier.
Email verification bypass. As covered in a previous post in this series account activation without completing the email verification step. The activation endpoint validates the token but not the prerequisite state that the token was meant to confirm.
The Server-Side State Check Pattern
The fix for workflow state skipping is always the same: the server maintains authoritative state for each workflow stage and verifies that state before processing any step that has prerequisites.
The workflow state is a property of the server's record of the user's journey, not a property of the request the client sends. The server does not ask the client "have you completed step 2?" it checks its own record of whether step 2 was completed for this user.
Category Three: Quantity and Limit Abuse
The Core Pattern
Quantity and limit abuse flaws occur when an API accepts a quantity or count value without validating it against the business rules that govern what quantities are permitted for this user, this account, or this transaction.
The vulnerability manifests in several forms: negative quantities that reverse transactions, quantities that exceed per-user or per-account limits, zero quantities that create transactions with no value, and quantities that exploit rounding behavior in downstream calculations.
The Minimal Example
A referral reward system allows users to redeem referral credits:
The OpenAPI spec defines amount as a number. Schema validation passes for any numeric value.
The business rules say: a user can redeem up to their available credit balance, in amounts between $1 and $500. These rules are not in the spec. They need to be enforced by the server.
Negative amount submission: "amount": -50 if the server applies a negative redemption, it charges the user's account rather than deducting from credits. The endpoint was designed to debit credits; a negative value turns it into a credit-adding operation.
Zero amount submission: "amount": 0 if the server processes a zero redemption, it may create a successful transaction record with no value. Depending on the downstream logic, this could satisfy a "has redeemed credits" state check that unlocks additional features, even though no credits were actually redeemed.
Above-limit submission: "amount": 50000 if the server does not validate against the user's available credit balance, the user can redeem more than they have. Depending on how negative balances are handled, this might result in unlimited credit usage.
Variants Worth Testing
Seat count manipulation in SaaS billing. APIs that allow account administrators to add or remove user seats often accept a quantity. Testing whether the quantity can be set to zero (removing all seats and disabling billing), to a negative number (potentially triggering a refund calculation), or to a value that exceeds the plan maximum without triggering an upgrade.
Coupon usage count. Coupon or promotion code systems that track usage counts. Testing whether the usage count can be manipulated by submitting multiple simultaneous requests (race condition), whether the same coupon can be applied multiple times in a single transaction, or whether coupon stacking produces results that exceed intended discount limits.
API rate limit bypass via quantity. APIs with per-request rate limits that accept a count or batch_size parameter. Testing whether setting count: 10000 in a single request processes the full batch without applying per-item rate limiting. One request at ten thousand items might bypass both the request-level rate limit and the per-item limits that would apply to ten thousand individual requests.
Free tier limit manipulation. Free tier APIs that enforce limits on a specific resource storage, API calls, active projects via the API parameters themselves. Testing whether the limit can be bypassed by manipulating the quantity of a resource creation request to exceed the tier maximum.
Decimal precision exploitation. Financial calculations that use floating-point arithmetic and have specific precision requirements. Testing whether submitting values like 0.0001 or values with many decimal places produces rounding behavior that can be exploited to accumulate value through many small transactions.
Why These Flaws Are Invisible to Schema Validation
The fundamental reason business logic flaws survive schema validation is that OpenAPI specifications describe the structure of a contract, not the semantics of the business rules that the contract is supposed to enforce.
Consider the quantity example. An OpenAPI spec might describe the amount field as:
The minimum: 0 constraint prevents negative values at the schema level. But it does not enforce:
- That the amount does not exceed the user's available balance
- That the amount falls within the per-transaction limits for the user's account tier
- That the user has not already redeemed the maximum allowed this period
- That the transaction amount does not exploit precision rounding in the downstream payment processor
All of these are business rules. They require knowledge of the user's current state, the account's configuration, and the business policies that govern this operation. Schema validation has access to none of these it sees only the structure of the request, not the context in which the request is being made.
This is not a limitation of OpenAPI or of schema validation it is a correct characterization of what those tools do. Schema validation is excellent at what it is designed for. The mistake is treating it as a security control for a category of vulnerability it was never designed to address.
The Testing Approach That Actually Finds These
Finding business logic flaws requires testing the application with an understanding of the business rules it is supposed to enforce and then systematically asking whether those rules are actually enforced, or whether they are merely assumed.
The testing methodology differs by category.
For price manipulation: Identify every parameter in the API that relates to monetary value prices, totals, discounts, shipping costs, tax amounts, currency. For each, submit requests where these values are: negative, zero, extremely large, different from the server-calculated equivalent (if you can determine the server-side value), and in unexpected currencies or units. Compare the resulting transactions against what the server should have charged.
For workflow state skipping: Map every multi-step process to its constituent API endpoints. For each endpoint that is not the first step, attempt to call it directly from an account that has not completed the prerequisites. Attempt to call step N-1 and N simultaneously. Attempt to repeat completed steps. Attempt to move backward in the workflow.
For quantity and limit abuse: Identify every parameter that represents a count, quantity, amount, size, or duration. For each, test: negative values, zero, the maximum allowed value, one above the maximum, very large values, fractional values where integers are expected, and concurrent submissions of the same request (to probe race conditions in limit enforcement).
The unifying principle: the test asks whether the server enforces the business rule independently, or whether it trusts the client to have already enforced it. The answer is revealed by submitting requests that the business rule should reject and observing whether the server rejects them.
What This Means for Your Security Testing Program
The practical implication of business logic flaws being invisible to schema validation is that a security testing program built primarily around schema-based tools OpenAPI validators, contract testing frameworks, structural DAST scanners has a systematic blind spot for this vulnerability class.
This does not mean those tools are not worth using. Schema validation and contract testing are valuable. They catch structural errors early and maintain contract consistency across services. They are the right tools for the problems they address.
The blind spot requires a different tool: something that understands the application's behavior in terms of what requests produce, not just whether requests conform to the declared schema. That requires authenticated testing, because most business rules apply to authenticated users with specific account states. It requires stateful testing, because workflow state violations require tracking what has and has not happened in a session. And it requires adversarial intent the tester needs to ask "what happens if I try to skip this step?" rather than "does this request match the schema?"
The closest analog to this kind of testing, at scale, is an autonomous agent that creates real accounts, navigates real workflows, and then systematically probes whether the business rules are enforced by the server or merely assumed. Not a scanner that checks schemas an agent that behaves like a user who has read the spec and is looking for the rules it does not describe.
Closing: The Spec Describes the Contract. The Bug Is in What the Contract Doesn't Say.
OpenAPI is a contract language. It describes what an API accepts and what it returns. It is precise, machine-readable, and excellent at what it does.
Business logic is a different kind of contract one between the application and the business rules it was built to enforce. This contract is not written in YAML. It is implicit in the design decisions made when the feature was built: prices should come from the database, not from the client. Workflow step N should not complete before step N-1. Quantities should not exceed the user's entitlement.
These rules do not appear in the OpenAPI spec because OpenAPI is not designed to represent them. They are enforced or not enforced in the application code that runs when the API endpoint is called.
The gap between the schema and the business rule is where the vulnerabilities live. A request that is structurally correct but semantically wrong passes schema validation and reaches the application code. Whether the application code enforces the business rule or trusts the client to have already done so is the question that schema validation cannot answer.
Answering it requires testing the application with attacker intent not to break the schema, but to break the rule. Those are different tests with different tools and a different outcome when they succeed.
Axeploit tests business logic as part of its application security coverage not by validating requests against schemas, but by exercising APIs as authenticated users with attacker intent: submitting negative prices, calling workflow endpoints out of sequence, testing quantity parameters at and beyond their limits. These tests require knowing what the business rule is supposed to be, which is why they require an agent that can navigate the application, understand its data model, and probe the specific endpoints where the rules matter. The spec says what the API accepts. Axeploit tests whether the application enforces what the spec doesn't say.
