Business logic flaws and race conditions

Overview

Business logic flaws abuse legitimate features in unintended ways (coupon reuse, negative quantities, skipped steps, client-controlled price/role) — scanners miss them. Race conditions (TOCTOU) exploit the gap between check and act with concurrent requests. Fixes: server-side invariants and atomic critical sections.

Why it matters

Logic and race bugs are high-impact (financial loss, privilege gain) and largely invisible to automated tools, so they're where human testers add the most value. They also connect web testing to the same TOCTOU concept seen in systems C code.

Core concepts

Logic abuse. Unintended sequences/values via legitimate features. Mass assignment. Trusting client-sent fields (role, price). TOCTOU race. Concurrent requests split check-then-act. Fixes. Server-side state/invariants; atomic transactions, locking, idempotency keys.

Lesson

Not every vulnerability is a payload. Some of the highest-impact bugs are the app doing exactly what it was told — just not what was intended.

Business logic flaws

Abusing legitimate features in unintended sequences or values:

• Applying a discount code multiple times; negative quantities yielding a refund.
• Skipping a step in a multi-stage flow (go straight to "confirm purchase" without "pay").
• Manipulating a price or currency the client shouldn't control.
• Promoting yourself by sending a role field the server trusts (mass assignment). These require understanding the application's intent, which is why automated scanners miss them and skilled humans find them.

Race conditions (TOCTOU)

When the app checks a condition and acts on it in two steps, concurrent requests can slip between:

• Redeem a single-use coupon, withdraw "available" balance, or use a one-time token N times at once before the state updates. Send many parallel requests in a tight window and the check-then-act gap is exploited. (This is the web sibling of the TOCTOU file-race bugs in the secure-coding C exercises.)

Fixes

• Enforce invariants and state transitions server-side; never trust client-supplied prices/roles/steps.
• For races: make the critical section atomic — database transactions with proper locking, idempotency keys, atomic decrements — so check and act can't be split.

Summary

The subtlest web bugs are logic abuses and race conditions — the app working as coded but not as intended. They demand understanding intent and concurrency, and are fixed with server-side invariants and atomic operations, not input filtering.

Practice with these exercises

• Token-bucket rate limiter (single slot)