Business Logic Vulnerabilities: Price Manipulation, Workflow Bypass, and Race Conditions

Business logic vulnerabilities are fundamentally different from technical vulnerabilities like SQL injection or XSS. Instead of exploiting implementation flaws in code, they exploit flaws in the rules and workflows of an application — cases where the application does what it was coded to do, but not what it was intended to do. These vulnerabilities are often missed by automated scanners entirely, making them high-value targets in bug bounty programs.

What Makes Business Logic Vulnerabilities Different

A technical vulnerability (e.g., unsanitized input reaching a SQL query) follows a predictable pattern that scanners can detect. Business logic flaws require understanding the application's intended behavior and asking: "what happens if I do this in an unexpected order?" or "what if I send negative quantities?" Successful exploitation often yields the same impact as technical vulnerabilities — financial loss, privilege escalation, account takeover — but requires deeper application knowledge.

Price Manipulation

Negative Quantities

Shopping carts that accept negative quantities may apply a negative total — effectively crediting the attacker's account or producing a negative checkout price:

# Normal cart update:
POST /api/cart/update
{"item_id": 42, "quantity": 2}

# Negative quantity attack:
{"item_id": 42, "quantity": -1}

# Combined with a high-price item to get a net-negative total:
{"items": [
  {"item_id": 100, "quantity": 1},   # $500 item
  {"item_id": 99, "quantity": -2}    # -2x $300 item = -$600
]}
# Total: -$100 (store owes attacker $100)

Integer Overflow / Underflow

# Some systems use 32-bit integers for prices (max: 2,147,483,647 cents)
# A sufficiently high quantity may overflow to a negative number:
{"item_id": 1, "quantity": 2147483648}
# Price: $9.99 * 2,147,483,648 = overflows to negative value

Client-Side Price Manipulation

Applications that calculate prices client-side and submit the final price to the server are trivially exploitable. Intercept the checkout request and modify the price field directly:

# Intercept and modify:
POST /api/checkout
{"items": [...], "total": "0.01", "currency": "USD"}

Coupon Code Stacking and Reuse

# Test coupon stacking:
# Apply coupon A, then apply coupon B — does the second replace or stack?
POST /api/coupon/apply {"code": "SUMMER20"}  # 20% off
POST /api/coupon/apply {"code": "WELCOME10"} # 10% off
# If both apply: 30% total discount

# Test coupon reuse after removal:
POST /api/coupon/apply {"code": "ONETIME50"}
POST /api/coupon/remove {"code": "ONETIME50"}
POST /api/coupon/apply {"code": "ONETIME50"}  # Can it be applied again?

# Test applying a coupon intended for another user:
# (Combine with IDOR testing — reference another user's cart ID)

Workflow Step Skipping

Multi-step processes (checkout flows, registration, document signing) often protect only the first and last steps. Test whether intermediate steps can be skipped:

# E-commerce checkout flow:
# Step 1: /checkout/cart
# Step 2: /checkout/shipping
# Step 3: /checkout/payment
# Step 4: /checkout/review
# Step 5: /checkout/confirm

# Test: skip from step 1 directly to step 5:
GET /checkout/confirm

# Also test: complete step 5 twice (double-purchasing at single-use discount price)

Real-world HackerOne reports have documented cases where navigating directly to a confirmation page triggered order creation without payment processing, or where completing a payment step multiple times charged the card once but credited the account multiple times.

2FA Bypass

Two-factor authentication is frequently bypassable through logic flaws:

• Direct navigation: After entering valid credentials, navigate to an authenticated page without completing 2FA — the session may already be partially authenticated.
• Response manipulation: Intercept the 2FA failure response and change {"mfa_required": true} to {"mfa_required": false}.
• Code reuse across accounts: Generate a TOTP code for your account and test if it works on the victim's 2FA endpoint (only relevant if codes are not account-specific).
• Backup code brute force: Backup codes are often shorter and simpler than TOTP codes. Test if they are rate-limited.

Account Merge for Account Takeover

Applications allowing account linking or merging create complex authorization states. Classic attack pattern:

# Scenario: app allows linking social accounts
# Step 1: Attacker registers with [email protected] (unverified)
# Step 2: Attacker links their Google account to this unverified email account
# Step 3: Victim later tries to register with the same email address
# Step 4: App merges accounts or fails in an exploitable way
# Step 5: Attacker's Google login now accesses victim's account (once victim verifies email)

This pattern has appeared in multiple critical bug bounty reports. Also test what happens when the same email is registered via two different OAuth providers — Facebook and Google both returning the same email address. Does the app merge or create duplicate accounts? Is the merge authenticated?

Gift Card / Store Credit Race Conditions

Race conditions occur when multiple simultaneous requests exploit a time window between a check (balance verification) and an action (balance deduction). The classic "time-of-check to time-of-use" (TOCTOU) vulnerability:

# Gift card redemption race condition test:
# Send 20 simultaneous redemption requests for the same gift card:

for i in $(seq 1 20); do
  curl -s -X POST https://target.com/api/redeem     -H "Authorization: Bearer $TOKEN"     -d '{"code": "GIFT-CARD-1234"}' &
done
wait

# If more than one succeeds → race condition confirmed
# The gift card balance was deducted less than 20 times but credited 20 times

Use Burp Suite's parallel request feature (Turbo Intruder) to send requests with minimal timing offset. The most effective race condition attacks send all requests within a single TCP connection using HTTP/2 multiplexing.

Testing Methodology

1. Map every multi-step workflow in the application and test direct navigation to later steps.
2. Identify any numeric input (quantities, prices, discount percentages) and test negative values and extreme values.
3. Find coupon/voucher redemption endpoints and test stacking and reuse.
4. Identify balance-affecting operations and test for race conditions with Burp Turbo Intruder.
5. Test every authentication flow for response manipulation and step skipping.
6. Map account linking/merging features and probe for pre-account-takeover conditions.

Business logic testing pairs naturally with API testing — use the API Security Studio to replay modified requests across all workflow steps. For related authentication bypasses, see our Broken Authentication Testing guide. Many business logic vulnerabilities are only discoverable after thorough recon — use the Recon Hub to enumerate all endpoints first.