race-condition

Testing race conditions involves sending synchronized request bursts to state-changing endpoints to reveal duplicate successes or inconsistent server-side state. This Skill validates non-atomic behavior by correlating concurrent request evidence with final server-side state verification.

HTTP/2 single-packet bursts tighten request spacing to test rate-limit bypasses and concurrent HTTP abuse. This transport-level timing technique, alongside HTTP/1.1 last-byte synchronization, helps identify non-atomic operations in web application endpoints.

A TOCTOU vulnerability occurs when one-time operations like email verification or coupon redemption fail to execute atomically. Concurrent requests can bypass intended controls by exploiting the time gap between checking state and updating it, causing duplicate effects.

Race condition testing applies directly to multi-step workflow validation by stressing state transitions with synchronized bursts. It confirms whether multi-step processes maintain integrity under concurrent HTTP abuse or reveal non-atomic behavior during transfers and verifications.

Concurrent requests cause duplicate successes when endpoints lack atomic transaction handling. Sending synchronized bursts exposes race conditions by verifying the final server-side state, revealing inconsistent outcomes where intended one-time controls fail under simultaneous load.

The best way to confirm duplicate effects is through server-side state verification after sending synchronized request bursts. This requires correlating evidence from concurrent HTTP abuse to validate that the final application state reflects inconsistent or duplicated outcomes.