race-condition

Tests web APIs for race condition and TOCTOU vulnerabilities using concurrent request scripts.

2|1|Updated Aug 28, 2026
One-click install
npx skills add https://github.com/lycheer1126/xs-bigdan --skill race-condition-lycheer1126
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: race-condition
Source: https://github.com/lycheer1126/xs-bigdan/tree/main/knowledge/skills/race_condition
Command: npx skills add https://github.com/lycheer1126/xs-bigdan --skill race-condition-lycheer1126

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Business-logic endpoints like coupon redemption, withdrawals, and order creation often lack atomicity checks, and manually verifying concurrency flaws is slow and unreliable. This Skill provides a structured methodology and ready-to-adapt concurrent scripts to detect race condition and TOCTOU vulnerabilities during authorized security testing. ## Core Features & Use Cases - Scenario-Classified Testing: Covers eight prioritized scenarios including coupon double-spending, withdrawal/transfer concurrency, inventory overselling, invite code reuse, check-in point duplication, state-transition races, file upload races, and password reset TOCTOU. - Go and Python PoC Templates: Provides concurrent request scripts using Go goroutines and Python asyncio/aiohttp that can be adapted to target endpoints. - Detection Signals and Checklists: Supplies keyword-based endpoint identification (couponCode, withdraw, order, invite, checkin) and a 3-round verification standard with concurrency levels of 10/20/50. - Use Case: During an authorized SRC assessment, JS analysis reveals a /api/coupon/use endpoint. You adapt the Go template to fire 20 concurrent redemption requests and confirm the same coupon was applied multiple times, producing a documented finding. ## Quick Start Ask the agent to run a race condition test against the coupon redemption endpoint using 20 concurrent requests with the test account credentials.

Frequently Asked Questions about race-condition

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I test an API for race condition vulnerabilities?

Send multiple concurrent requests (10-50) to endpoints performing limited or atomic operations like coupon redemption or withdrawals, then check if more operations succeeded than allowed. Run at least 3 rounds since races are not always reproducible, and use Go goroutines or Python asyncio for precise timing.

What endpoints should I prioritize for concurrency testing?

Prioritize payment and withdrawal endpoints (highest impact), then coupon/discount redemption, inventory-limited purchases, invite code registration, and check-in or points systems. Look for parameters like couponCode, amount, balance, inviteCode, or order state transitions in API requests.

Go vs Python for writing race condition test scripts?

Go goroutines offer lighter-weight concurrency and tighter request timing, making them preferable for race testing. Python with asyncio and aiohttp also works and is faster to write, but the GIL and event loop scheduling can introduce slightly more timing jitter between requests.

How many concurrent requests are needed to confirm a race condition?

Start with 5-10 concurrent requests and scale up to 20-50 across at least 3 rounds. If more than one request succeeds where only one should, the vulnerability exists; a single successful round out of three is sufficient confirmation.

What are the safety limits when running concurrency tests?

Only test against authorized targets using dedicated test accounts, never real user funds or coupons. Keep concurrency between 5 and 50 requests, stop immediately if the service slows or errors, and use virtual currency or staging environments for payment-related tests.