Business Logic Attacks

A business logic attack exploits flaws in the rules a system follows rather than holes in its security controls. The attacker uses valid credentials and legitimate API calls, then makes the system behave in ways nobody designed for: negative transfers, replayed refunds, race-condition withdrawals, mass assignment that promotes a regular user to admin. This article catalogs the patterns by category and shows where the rules tend to break.

The bank's transfer system had passed every security audit. Encrypted connections, multi-factor authentication, session timeouts, all the controls a regulator could want. So when First National lost $3.7 million overnight with no evidence of unauthorized access, the security team was baffled.

Detective Rachel Morrison spent her first three hours looking for the breach. There wasn't one. Every transaction showed valid credentials, approved sessions, and amounts within stated limits. The system had worked exactly as designed.

The breakthrough came when she asked what happens when someone transfers negative money.

The transfer form wouldn't allow it. But the API behind the form? It only checked that the amount field wasn't empty. A group of attackers had discovered this over months of testing, then spent a single night sending requests like "transfer -$500 from Account A to Account B." The system interpreted each negative transfer as a deposit into the source account.

3,700 transactions. $3.7 million created from nothing. By morning, the funds had been withdrawn through ATMs across three states.

This story is fictional, but the patterns are real.

Why This Matters

API 101 explained what APIs are and why they matter. This article goes deeper into how business logic attacks actually work.

These attacks don't break security. They exploit gaps between what systems should do and what they actually do. An attacker using valid credentials to make a system behave unexpectedly doesn't trigger security alerts. The transactions look legitimate because, technically, they are. The rules just weren't written correctly.

Understanding these patterns matters because business logic flaws don't show up in vulnerability scanners. They hide in assumptions that seemed reasonable when the system was designed.

Mathematical Logic Flaws

Computers handle numbers precisely, but that precision can backfire when developers make assumptions about what values users will provide.

Negative Value Attacks

The most straightforward mathematical exploit: if a system doesn't explicitly reject negative numbers, they might be processed literally.

How it works:

A refund API expects positive amounts. An attacker intercepts the request and changes amount: 50.00 to amount: -50.00. If the system just subtracts the refund from the order total (or adds it to the customer's credit), a negative refund becomes a payment from the company to the attacker.

The same logic applies to transfers, loyalty points, inventory quantities, and anywhere else numbers move between accounts. The system does exactly what the code says. The code just never anticipated negative input.

Integer Overflow

Computers store numbers in fixed-size containers. A 32-bit signed integer can hold values from roughly -2.1 billion to +2.1 billion. What happens when you add 1 to 2,147,483,647?

The number wraps around to -2,147,483,648.

How it works:

An attacker purchases 2,147,483,647 items at $1 each. The system calculates the total, but the multiplication overflows the integer limit. Depending on how the code handles this, the total might become negative, zero, or a much smaller positive number. The order processes at the wrong price.

This isn't theoretical. Gaming platforms, loyalty programs, and e-commerce sites have all suffered overflow attacks. Any system that calculates totals without checking for overflow is vulnerable.

Rounding Errors

Financial systems round fractional cents. When millions of transactions happen, consistent rounding in one direction adds up.

How it works:

A payroll system calculates taxes on each employee's paycheck. The real tax is $127.456, but the system rounds down to $127.45 and sends that to the government. The missing $0.006 goes to an account the attacker controls. Across 10,000 employees paid weekly, that's $60 per week diverted in amounts too small to notice individually.

This is the "salami slicing" technique popularized by the movie Office Space. The idea predates the film and is sometimes traced to programmer folklore from the mainframe era, but well-documented public prosecutions are harder to pin down than the legend suggests, so treat the historical examples cautiously. The mechanism is real regardless. The vulnerability requires access to modify where the rounded-off fractions go, and complex financial calculations with many intermediate steps still create opportunities.

Workflow Manipulation

Multi-step processes assume users will follow the intended path. APIs often don't enforce this assumption.

Step Skipping

How it works:

An e-commerce checkout has four endpoints:

1. /cart/review (view cart)
2. /checkout/shipping (enter address)
3. /checkout/payment (enter card)
4. /checkout/complete (finalize order)

The website guides users through each step. But what if an attacker calls /checkout/complete directly, skipping payment? If the API doesn't independently verify that payment succeeded before creating the order, merchandise ships without payment.

This happens more than you'd expect. Developers assume the frontend will enforce the workflow. The frontend is just JavaScript running in the attacker's browser.

State Transition Abuse

Complex processes have states: pending, approved, shipped, completed. The rules for moving between states often have gaps.

How it works:

An insurance claim starts as "pending." After review, it moves to "approved" or "denied." The API has separate endpoints for each transition.

An attacker submits a claim (status: pending), then immediately calls the approval endpoint. If the system checks "is this claim pending?" (yes) without checking "has this claim been reviewed?" (no), the claim approves itself.

Similar patterns appear in loan applications, refund requests, and any workflow with multiple approval stages. The attacker races between states faster than the system expected.

Race Conditions

When two things happen simultaneously, order matters. Race conditions exploit the gap between checking a value and updating it.

How it works:

An account has $1,000. The attacker sends 10 simultaneous withdrawal requests for $1,000 each. The system checks all 10 requests at nearly the same instant. Each check sees $1,000 available. Each check approves. The updates happen afterward, but by then all 10 transactions are in flight.

Result: $10,000 withdrawn from a $1,000 account.

A race condition of this broad class destroyed Flexcoin, a Bitcoin exchange, in March 2014. The specific mechanism was slightly different from the simultaneous-withdrawal pattern above: attackers exploited concurrent inter-user transfers that allowed one account to go negative while another received credit, then drained the positive balances. Roughly 896 Bitcoin (about $600,000 at the time)^[3] disappeared in minutes, and the company shut down within days. The lesson is the same. Any check-then-update sequence without proper locking is a candidate for this attack family.

Economic Logic Exploitation

These attacks target the business rules that calculate prices, apply discounts, and handle currency. They are a staple of e-commerce fraud because the merchant absorbs the loss directly.

Discount Stacking

How it works:

A site offers three promotions: 10% off for new customers, 15% off for the summer sale, and 20% off for orders over $500. Each promotion applies sequentially:

$1,000 × 0.90 × 0.85 × 0.80 = $612

But what if the attacker applies the same code multiple times? Or applies percentage discounts that compound unexpectedly?

$1,000 × 0.50 × 0.50 × 0.50 = $125 (three 50% codes) $1,000 × 0.50 × 0.50 × 0.50 × 0.50 = $62.50 (four codes)

Some systems have accidentally allowed discounts exceeding 100%, resulting in negative prices where the company pays the customer.

Price Tampering

How it works:

The shopping cart sends a request including the item ID and the price. The server trusts this price instead of looking it up from the database.

The attacker intercepts the request and changes "price": 1299.99 to "price": 1.99. The server processes the order at $1.99.

This sounds too simple to be real, but it happens. Developers sometimes include prices in requests for performance (avoiding database lookups) or during migrations between systems. If the server doesn't validate the price independently, it processes whatever it receives.

Currency Arbitrage

How it works:

Exchange rates fluctuate. Systems cache rates to avoid constant lookups. Attackers exploit the gap between the cached rate and the real rate.

1. Buy currency A when the cached rate is favorable
2. Wait for the rate to update
3. Sell currency A at the new rate
4. Repeat

More sophisticated versions exploit rounding differences between currency pairs, or delays between when rates update in different parts of a system.

Authorization Boundary Violations

Authentication proves who you are. Authorization determines what you can do. Many systems conflate these, creating opportunities for escalation.

Horizontal Privilege Escalation

You can access your data. I can access my data. What stops you from accessing my data?

How it works:

A banking app shows your account at /api/accounts/12345. The "12345" is your account number. What happens if you change the URL to /api/accounts/12346?

If the system only checks "is this user logged in?" without checking "does this user own account 12346?", you see someone else's account.

This is called horizontal escalation because you're moving sideways to another user at the same privilege level. It's shockingly common. The fix is straightforward (check ownership), but developers sometimes forget, especially in complex systems with many data types.

Vertical Privilege Escalation

Moving from regular user to administrator.

How it works:

A profile update endpoint accepts a JSON body with fields like name and email. What if the attacker adds "role": "admin" to the request?

If the server blindly copies all request fields to the database record, the attacker just promoted themselves. This is called mass assignment, and in the OWASP API Security Top 10 it's classified under API3:2023, Broken Object Property Level Authorization^[2] (the 2023 edition merged the older "Mass Assignment" and "Excessive Data Exposure" categories into this single property-level concept). It's caught many systems that assumed the frontend would only send expected fields.

Other vertical escalation patterns:

• Calling administrative endpoints directly (they exist; they're just not linked from the UI)
• Manipulating session data that includes role information
• Exploiting cached permissions that don't update when roles change

Broken Object Level Authorization (BOLA)

BOLA is the API-specific form of the broader IDOR (Insecure Direct Object Reference) pattern. The two overlap, but BOLA emphasizes the missing authorization check on object access through APIs, while IDOR was originally a more general web-application term. In the OWASP API Security Top 10 it's listed as API1:2023, Broken Object Level Authorization^[1], the #1 risk in the 2023 edition. Conceptually, it's the generalized version of horizontal escalation: anywhere a user-provided ID grants access to a resource without proper authorization checks.

How it works:

• /api/invoices/789 shows invoice 789
• /api/documents/abc123 downloads document abc123
• /api/messages/456 displays message 456

If changing the ID shows different users' data, that's BOLA. The vulnerability is that the system trusts the ID as authorization rather than checking whether the requesting user should have access. APIs are especially prone to this because they expose object IDs directly in URLs and request bodies.

Token and Session Attacks

Modern systems use tokens for authentication. Those tokens become targets. Many account-takeover attacks end at the token layer rather than the password screen.

JWT Manipulation

JSON Web Tokens (JWTs) carry identity information in a signed format. The signature prevents tampering, unless the system doesn't verify it properly.

How it works:

JWTs have three parts: header, payload, signature. The header specifies the signing algorithm. Some older systems accepted "none" as an algorithm, meaning no signature was required.

Attacker intercepts their token, changes the payload (setting "role": "admin"), changes the header to "alg": "none", removes the signature, and sends it back. If the server accepts the "none" algorithm, it processes the modified token as valid. Mainstream JWT libraries have patched this since Tim McLean's March 31, 2015 disclosure on Auth0↗^[5], so it's mostly a vintage attack now, but you'll still find it in legacy systems and custom implementations.

The more current concern is algorithm confusion, often framed as HS256 versus RS256. RS256 is asymmetric: the server signs with a private key and clients verify with the public key. HS256 is symmetric: the same secret signs and verifies. If an attacker can fetch the server's public RSA key (which is, by design, public) and resubmit a token whose header says "alg": "HS256", a vulnerable verifier will use the public key as the HMAC secret. The attacker can then forge any token they like. Other JWT attacks exploit weak signing keys, "kid" parameter injection, or timing issues in token validation. RFC 8725 (JSON Web Token Best Current Practices)↗^[4] codifies the canonical defenses: reject the none algorithm explicitly and pin the expected algorithm at verification time. PortSwigger's Web Security Academy JWT track↗^[6] has interactive labs for both attacks.

OAuth Flow Hijacking

OAuth lets you log in with Google, Facebook, or other providers. The flow involves redirects between sites, and each redirect is an opportunity for manipulation.

How it works:

1. You click "Login with Google"
2. Your site redirects to Google
3. You authenticate with Google
4. Google redirects back to your site with a code
5. Your site exchanges the code for an access token

An attacker can intercept at step 4 if the "redirect back" URL isn't properly validated. They might inject their own URL to receive the code, or manipulate the state parameter to hijack another user's session.

The modern defense is PKCE (Proof Key for Code Exchange, pronounced "pixie"). The client generates a random code_verifier at the start of the flow, sends a hash of it (code_challenge) along with the authorization request, and sends the original verifier when exchanging the code for a token. An attacker who intercepts the code can't redeem it without the matching verifier, which never left the client. PKCE was originally designed for public clients (mobile and single-page apps) where a client secret can't be safely stored, but the OAuth 2.1 draft now requires PKCE for all authorization-code-flow clients, confidential ones included. If your platform's OAuth flow doesn't use PKCE, that's worth flagging.

Session Fixation

Force a victim to use a session ID you control.

How it works:

1. Attacker visits the site and gets session ID "xyz"
2. Attacker sends victim a link containing session ID "xyz"
3. Victim clicks the link and logs in
4. The session "xyz" is now authenticated
5. Attacker uses session "xyz" to access victim's account

This works when the session ID doesn't change after login. The fix is issuing a new session ID upon authentication, but legacy systems often don't.

Input Validation Exploits

Systems make assumptions about the format and type of input. Violating those assumptions reveals flaws.

Type Confusion

How it works:

An API expects "quantity": 5 (a number). What if you send "quantity": "five" (a string)? Or "quantity": [5, 5, 5] (an array)?

Depending on the programming language and how loosely the code is written:

• Strings might be converted to 0 or cause errors that bypass validation
• Arrays might be processed multiple times or have their first element extracted
• Objects might overwrite internal state

Each unexpected behavior is a potential exploit.

Encoding Bypass

Input filters block dangerous values. Encoding those values can slip past filters.

How it works:

A filter blocks the string "admin" in requests. The attacker sends:

• URL encoding: %61%64%6d%69%6e (admin in hex)
• Unicode: ａｄｍｉｎ (fullwidth characters)
• Double encoding: %2561%2564%256d%2569%256e

If the filter runs before decoding, or doesn't decode all layers, the blocked value gets through.

Parameter Pollution

Send the same parameter multiple times with different values.

How it works:

Request: ?discount=10&discount=50

Which value does the server use? It depends on the framework:

• Some use the first value (10)
• Some use the last value (50)
• Some concatenate them
• Some create an array

Attackers test which behavior occurs, then exploit discrepancies. If the security filter checks the first value but the application uses the last, the filter sees 10% while the application applies 50%.

Key Takeaways

• Business logic attacks use the system correctly. Every request has valid authentication, approved credentials, and allowed actions. The flaw is in the rules themselves, not in how they're enforced.
• The frontend is not a security boundary. Any validation in a mobile app or website can be bypassed by calling the API directly. Server-side validation is the only validation that counts.
• Assumptions are vulnerabilities. Developers assume positive numbers, sequential workflows, single requests, and honest users. Attackers test every assumption.
• Race conditions require precise timing. They're hard to find in testing but devastating in production. High-volume financial systems are especially vulnerable, and agentic probing tools make these timing windows easier than ever to discover.
• Authorization must be checked at every access. Proving identity (authentication) doesn't prove permission (authorization). Each data access needs its own ownership check.

What's next: API Investigation covers how fraud analysts reconstruct what happened after a business logic attack, including evidence types and timeline analysis.

References

1. OWASP API1:2023 — Broken Object Level Authorization↗ - The #1 API risk; per-object ownership checks are required at every access.

2. OWASP API3:2023 — Broken Object Property Level Authorization↗ - Consolidates the 2019 "Excessive Data Exposure" and "Mass Assignment" categories under a single property-level concept.

3. OCCRP — Second Bitcoin Exchange Shuts Down After $600,000 Heist (March 2014)↗ - Confirms 896 BTC stolen from Flexcoin, valued at approximately US$600,000 at the time.

4. RFC 8725 — JSON Web Token Best Current Practices↗ - §3.1 prohibits accepting none; §3.2 covers algorithm-confusion defenses.

5. Tim McLean — Critical Vulnerabilities in JSON Web Token Libraries (Auth0, March 31, 2015)↗ - The original disclosure of the none algorithm and HS256/RS256 confusion attacks.

6. PortSwigger Web Security Academy — JWT Attacks↗ - Free interactive labs for the none attack, algorithm confusion, and kid injection.

Key Terms

• Business logic attack: Exploiting flaws in application rules rather than security controls, using valid credentials to make systems behave unexpectedly.
• Race condition: A vulnerability where multiple simultaneous requests exploit the gap between checking and updating a value.
• Integer overflow: When a number exceeds its storage limit and wraps to an unexpected value (often negative).
• Horizontal escalation: Accessing another user's resources at the same privilege level.
• Vertical escalation: Gaining higher privileges than intended, such as regular user becoming admin.
• BOLA (Broken Object Level Authorization): The API-specific form of the broader IDOR pattern and the #1 API vulnerability per OWASP (API1:2023). When changing a user-provided ID grants access to another user's data without authorization checks.
• JWT (JSON Web Token): A signed token format carrying identity information, vulnerable if signature verification is weak.
• Mass assignment: When a server blindly copies all request fields to a database record, allowing attackers to modify fields they shouldn't access.
• Parameter pollution: Sending the same parameter multiple times to exploit inconsistent handling.
• Session fixation: Forcing a victim to use an attacker-controlled session ID.