There's a category of API attack that doesn't show up in signature databases, doesn't trigger WAF rules, and doesn't register as anomalous at any individual request level. It uses valid credentials, makes well-formed requests, and hits endpoints that are operating exactly as their developers intended. The only thing wrong is the intent behind the calls — and intent isn't something a rules engine can parse.
This is the category commonly labeled "business logic attacks," and it represents some of the most consequential API exploitation happening today. OWASP's API Security Top 10 2023 dedicates three separate entries to the problem space: API1 (Broken Object Level Authorization), API5 (Broken Function Level Authorization), and API6 (Unrestricted Access to Sensitive Business Flows). The fact that it takes three categories to describe the attack surface tells you something about how multidimensional the problem is.
What Makes a Business Logic Attack Different
Every API has a set of operations it's designed to perform and a set of assumptions built into its authorization model. A business logic attack exploits the delta between those assumptions and reality — usually by finding sequences of calls, object references, or state transitions that the authorization logic doesn't adequately restrict.
The canonical example is BOLA — Broken Object Level Authorization. An endpoint like GET /api/orders/{orderId} with a JWT-verified user token looks secure at the implementation level. Authentication is working. The token is validated. But if the authorization check is "is this user authenticated?" rather than "does this user own this order?", any authenticated user can retrieve any order by iterating orderId values. The attack is technically trivial — sequential integer enumeration, or UUID guessing with a large enough wordlist — and yields data that belongs to other users at scale.
Price manipulation attacks follow a different pattern. Consider a checkout API with a sequence: POST /cart, POST /cart/{id}/apply-coupon, POST /checkout/calculate, POST /checkout/confirm. If the server calculates price at the calculate step and accepts a client-provided price at the confirm step — or worse, if coupon application doesn't re-validate the cart contents at confirmation — an attacker can apply a valid coupon, remove items, re-add them at full price in a sequence that results in a checkout total the backend never actually recalculated. This isn't a theoretical attack; workflow sequence abuse in checkout APIs is well-documented in bug bounty reports across the e-commerce sector.
Workflow bypass is the broader category: finding paths through your API's state machine that don't go through the validation steps your application logic assumes. A financial platform's KYC (Know Your Customer) flow might gate account creation through a four-step identity verification API sequence. If steps 3 and 4 can be called without completing steps 1 and 2 — because the authorization check looks at token validity, not workflow state — an attacker can create a verified account without actually completing verification. Each individual request is valid. The problem is sequence.
Why Rules Engines Miss These Attacks Completely
Web Application Firewalls and API gateway security policies operate on request content and structure. They check for known payload patterns (SQL injection, XSS), validate against OpenAPI schemas, enforce rate limits, and block based on IP reputation or known-bad user agents. These controls are useful and necessary. We're not arguing against deploying them.
But here's what a WAF cannot see: whether the user making a request is accessing data that belongs to them. Whether a sequence of calls to different endpoints constitutes a workflow bypass. Whether a user who has successfully authenticated and is making well-formed, correctly-authorized requests is systematically enumerating resources they don't own. None of these characteristics are visible in a single request in isolation.
Rules engines by definition operate on pattern matching. Business logic attacks don't match patterns in the request content — they match patterns in the request sequence, object traversal, and behavioral context. An attacker querying GET /api/users/4821/profile generates a request that is formally identical to the same user's legitimate request to their own profile at GET /api/users/4821/profile. The only difference is whether the requesting user is user 4821. The WAF sees the same request either way.
Rate limiting catches the volume-based expression of these attacks, sometimes. But sophisticated enumeration attacks are designed to stay under rate-limit thresholds — distributing calls across sessions, across time, or across a fleet of accounts operating in coordinated low-volume patterns. A credential campaign running 2 attempts per IP per minute across 200 IP addresses generates 400 attempts per minute in aggregate. No per-IP rate limit fires. No single-request rule matches. The attack runs indefinitely.
Detecting Logic Attacks Requires Behavioral Context
If you can't detect these attacks at the request level, you need to detect them at the behavioral level — which means maintaining state about how each authenticated entity interacts with your API over time and across endpoints.
For BOLA detection, this means tracking the distribution of object IDs accessed per session. A legitimate user accessing their orders exhibits a tight distribution centered on their own account's data — low entropy, high repetition of the same object IDs. An enumeration attack exhibits high entropy, wide dispersion across the ID space, a low ratio of successful responses to requests, and often a walking pattern through sequential or pseudorandom IDs. These two profiles are distinguishable with statistical confidence even at low per-minute call rates, if you're maintaining a per-entity behavioral model rather than evaluating each request independently.
For workflow bypass detection, you need a sequencing model: what calls typically precede a given endpoint invocation, and what happens when a call arrives without its expected precursors? This requires tracking call graph state per session — not just whether a token is valid, but where in the expected interaction sequence the current request falls. Endpoints invoked in unusual sequence positions are a high-confidence signal for workflow abuse attempts.
For price manipulation and multi-step fraud, the detection model looks at consistency between the state implied by earlier calls in a session and the state claimed or assumed by later calls. A checkout confirmation that assumes a cart state that doesn't match what was last recorded at the calculate step is suspicious regardless of whether any individual request was malformed.
A Scenario: Discount Abuse on a B2B Platform
Consider a SaaS platform serving small businesses — call it Verdo Commerce — with an API that supports volume discount codes. The discount logic: codes apply a percentage off orders above a minimum subtotal, calculated at checkout. The attack sequence: an attacker with a valid business account and a single valid discount code creates a cart, applies the discount code (valid), adds enough items to meet the minimum threshold (cart subtotal: $350, minimum: $300), calls the calculate endpoint to capture the discounted price, then removes items to bring the cart below the minimum, and calls the confirm endpoint using the previously calculated discounted total rather than requesting a fresh calculation. If the confirm endpoint trusts the client-provided total without re-running the price calculation, the discount is applied to a cart that doesn't qualify for it.
No WAF rule detects this. The discount code is genuine. The authentication is valid. Every individual request is well-formed and passes schema validation. Detection requires a model that compares the cart state at confirm-time against the cart state that was present when the discount was applied — a cross-request consistency check that is only possible if you're maintaining a behavioral session model, not just evaluating requests in isolation.
The Organizational Problem: Who Owns This?
One reason business logic attacks persist is that responsibility for preventing them is genuinely ambiguous. Application security teams typically own WAF rules and vulnerability scanning. Platform teams own API gateway configuration and rate limiting. Development teams own the application logic — the authorization checks, workflow state machines, and price calculation sequences that are the actual locus of the vulnerability. Security tooling tends to follow team ownership: appsec tools look at the security controls layer, not the application logic layer.
We're not saying the development team is at fault for writing vulnerable business logic. Designing authorization correctly across complex multi-step API workflows is genuinely hard, and the OWASP API Security Top 10's continued dominance of BOLA and related authorization flaws reflects how systematically difficult this is to get right. The problem is that even well-designed authorization logic can be abused at runtime if the behavioral context isn't being monitored. Correct code is a necessary but not sufficient condition for security against logic-layer attacks.
The detection gap — the space between "the code is correct" and "the code is being exploited through behavioral sequences the developer didn't anticipate" — is where runtime behavioral monitoring fills in. Not as a replacement for writing correct authorization logic, but as the layer that watches how your API is actually being used and surfaces patterns that indicate someone is probing for the boundaries of what your authorization model actually enforces.
That's the gap that WAFs were never designed to close. It's also the gap where most of the interesting attacks are happening right now.