Two individually valid requests can produce an invalid combined result. Each may observe the same available balance, unused coupon, or pending approval before either updates it. If the application separates the check from the state change, concurrent execution can violate the business rule.
These failures do not require bypassing login. They arise when the system's transaction behavior does not preserve the condition the product promises to enforce.
State the invariant before testing
OWASP's business-logic guidance discusses workflow integrity and concurrency risks that ordinary input validation may not detect. The business-logic security guidance provides a framework for reviewing these application-specific conditions.
An illustrative subscription service offers one trial credit per organization. The invariant is that the organization receives at most one credit, even if two administrators request it at the same time. A disabled button in one browser cannot enforce that condition across independent clients.
Identify the authoritative state change
Map the read that checks eligibility and the write that consumes it. Determine whether the database enforces the relationship through a transaction, conditional update, uniqueness constraint, or another appropriate mechanism. The choice depends on the operation and storage system.
Idempotency and concurrency controls are related but different. An idempotency key can connect repeats of the same logical request. It does not necessarily prevent two distinct requests from violating a shared balance or single-use rule. The underlying invariant still needs enforcement.
Use a bounded concurrent test
Create synthetic accounts and reversible test value in a dedicated environment. Submit a small, agreed number of concurrent requests for the same operation. Inspect the resulting ledger, entitlement, or status records and compare them with the expected invariant.
Repeat after a controlled timeout to exercise retry behavior. Record how many requests were accepted, which business transitions occurred, and whether partial updates remained. High request volume is not required to establish a race, and an unbounded load test can obscure the state transition being investigated.
Verify the fix at the business layer
After remediation, repeat the concurrent case and ordinary sequential use. A fix that rejects all requests may preserve the invariant while breaking the feature. Both permitted completion and prohibited duplication need verification.
Include adjacent operations that share the same state, such as applying and reversing a credit or approving and canceling a request. The report can identify the exact invariant tested and the observed final state. This gives product and engineering teams a shared explanation of the defect and its resolution, without relying on a generic scanner category to describe the business impact.
Sources
OWASP Web Security Testing Guide: Process Timing. The trial-credit scenario is illustrative.
