What is a race condition attack?

What is a race condition attack?

A race condition attack exploits a race window: a brief interval where two or more tasks operate on the same data at the same time, and the system's intended outcome depends on a specific order that the code does not enforce. The application is designed for sequential work. Concurrent requests collide. The collision is the bug. Forcing that collision is the attack.

Race windows often last milliseconds. They appear wherever you check a value, then act on it, without making that pair atomic. Classic cases are one-time coupons, balance withdrawals, inventory holds, and password-reset tokens. API abuse covers the business-flow version of the same problem: an allowed operation repeated or coordinated until the invariant breaks.

In September 2012 James Zhong abused a withdrawal race on Silk Road. Rapid, duplicated Bitcoin withdrawals extracted about 50,000 BTC. That is the same check-then-act pattern you still ship on a checkout route.

How does a coupon or double-spend race work?

A one-time coupon is the cleanest request-flow to hold in your head. The intended sequence is:

1. The client POSTs /checkout with coupon=SAVE20.
2. The server reads the redemption row: redeemed = false.
3. The server applies the discount and writes redeemed = true.
4. A later request sees redeemed = true and is rejected.

Two requests that arrive inside the race window both pass step 2 before either write lands:

The third request, arriving after the write, is rejected. The first two both looked valid. That is a limit-overrun attack: an imposed application limit (one redemption) is exceeded because the check and the update are not one operation.

A wallet or points balance is the same flow with a number instead of a flag. Two withdrawals read balance = 100, both subtract 100, both write balance = 0. You paid out 200 from an account that held 100. Call that a double-spend. The fix is not a longer sleep or a "please don't click twice" button. The fix is an atomic update that only succeeds for one writer:

1
UPDATE coupons
2
SET redeemed = true, redeemed_by = $user_id, redeemed_at = now()
3
WHERE code = $code AND redeemed = false;

If the statement reports zero rows updated, the coupon was already taken. Pair that with a unique constraint on code (and on any idempotency key you accept from the client) so a replay cannot insert a second redemption row.

What other race condition attacks exist?

Limit overrun is the common case. Two other shapes show up in reviews.

Single-endpoint. Many handlers key state on a session or object id. If two requests in the same session submit different usernames at once, both threads write the same row. A password-reset flow that stores {sessionId, username, email, token} can end with the victim's username and the attacker's email on the same token. The reset mail goes to the attacker. The collision is on the session key, not on a coupon flag.

Multi-endpoint. A process spans two routes that share state. A ride-share /request notifies every free driver; /accept pairs the first one. If two accept calls commit inside the same window, two drivers are assigned to one ride. The invariant ("exactly one driver") is not enforced at write time.

Any control that assumes "we already checked that" without holding the row, a lock, or a compare-and-swap is in this family. Static analysis (SonarQube, Coverity) and runtime checks for corrupted state help you find the windows. They do not close them.

How do you prevent race condition vulnerabilities?

Review every path that reads a shared resource and then writes it. Prefer a single database statement or an atomic primitive over an in-process lock when the writers can run on more than one machine. An in-memory mutex only serializes one process.

When you do need in-process synchronization, most languages give you the same four tools. A mutex lets one thread through. A semaphore lets N through. A monitor pairs a mutex with a condition so a consumer can wait until a producer signals. An atomic operation updates a single value without a lock.

The following TypeScript mutex serializes increments of a shared counter:

1
class Mutex {
2
  private isLocked = false;
3
  private waiting: (() => void)[] = [];
4

5
  async lock(): Promise<void> {
6
    while (this.isLocked) {
7
      await new Promise<void>((resolve) => this.waiting.push(resolve));
8
    }
9
    this.isLocked = true;
10
  }
11

12
  unlock(): void {
13
    if (!this.isLocked) {
14
      throw new Error("Mutex is not locked");
15
    }
16
    this.isLocked = false;
17
    const next = this.waiting.shift();
18
    if (next) next();
19
  }
20
}
21

22
const mutex = new Mutex();
23
let sharedCounter = 0;
24

25
async function increment() {
26
  for (let i = 0; i < 100000; i++) {
27
    await mutex.lock();
28
    sharedCounter++;
29
    mutex.unlock();
30
  }
31
}
32

33
await Promise.all([increment(), increment()]);
34
console.log(`Final counter value: ${sharedCounter}`);

The same mutex in Python:

1
import threading
2

3
shared_counter = 0
4
mutex = threading.Lock()
5

6
def increment():
7
    global shared_counter
8
    for _ in range(100000):
9
        mutex.acquire()
10
        shared_counter += 1
11
        mutex.release()
12

13
threads = [threading.Thread(target=increment) for _ in range(2)]
14
for thread in threads:
15
    thread.start()
16
for thread in threads:
17
    thread.join()
18

19
print(f"Final counter value: {shared_counter}")

And in Go:

1
package main
2

3
import (
4
  "fmt"
5
  "sync"
6
)
7

8
var (
9
  wg            sync.WaitGroup
10
  mutex         sync.Mutex
11
  sharedCounter int
12
)
13

14
func increment() {
15
  for i := 0; i < 100000; i++ {
16
    mutex.Lock()
17
    sharedCounter++
18
    mutex.Unlock()
19
  }
20
  wg.Done()
21
}
22

23
func main() {
24
  wg.Add(2)
25
  go increment()
26
  go increment()
27
  wg.Wait()
28
  fmt.Printf("Final counter value: %d\n", sharedCounter)
29
}

A counting semaphore is the same idea with a budget. Use it when a pool (two database connections, two file handles) can be shared, but not by everyone at once:

1
class Semaphore {
2
  private tokens: number;
3
  private waiting: (() => void)[] = [];
4

5
  constructor(tokens: number) {
6
    this.tokens = tokens;
7
  }
8

9
  async acquire(): Promise<void> {
10
    if (this.tokens > 0) {
11
      this.tokens--;
12
      return;
13
    }
14
    await new Promise<void>((resolve) => this.waiting.push(resolve));
15
  }
16

17
  release(): void {
18
    this.tokens++;
19
    const next = this.waiting.shift();
20
    if (next) next();
21
  }
22
}
23

24
const semaphore = new Semaphore(2);

1
import threading
2
import time
3

4
semaphore = threading.Semaphore(2)
5

6
def access_resource(thread_id):
7
    print(f"Thread {thread_id} is waiting to access the resource.")
8
    semaphore.acquire()
9
    print(f"Thread {thread_id} has accessed the resource.")
10
    time.sleep(1)
11
    print(f"Thread {thread_id} is releasing the resource.")
12
    semaphore.release()

1
func accessResource(id int, semaphore chan struct{}, wg *sync.WaitGroup) {
2
  fmt.Printf("Thread %d is waiting to access the resource.\n", id)
3
  semaphore <- struct{}{}
4
  fmt.Printf("Thread %d has accessed the resource.\n", id)
5
  time.Sleep(1 * time.Second)
6
  fmt.Printf("Thread %d is releasing the resource.\n", id)
7
  <-semaphore
8
  wg.Done()
9
}
10

11
func main() {
12
  var wg sync.WaitGroup
13
  semaphore := make(chan struct{}, 2)
14
  for i := 0; i < 5; i++ {
15
    wg.Add(1)
16
    go accessResource(i, semaphore, &wg)
17
  }
18
  wg.Wait()
19
}

A monitor adds a condition variable so a consumer can wait until a producer has work. Python's threading.Condition and Go's sync.Cond are the usual forms. Use a monitor when "the lock is free" is not enough and you also need "the data is ready."

Atomic operations skip the lock for a single integer update. TypeScript's Atomics.add on a SharedArrayBuffer and Go's sync/atomic are the primitives. Python does not ship an equivalent integer atomic in the standard library; use a lock, or multiprocessing.Value across processes. Do not treat a read / increment / write as atomic just because it fits on one line.

1
const buffer = new SharedArrayBuffer(4);
2
const sharedCounter = new Int32Array(buffer);
3

4
async function increment() {
5
  for (let i = 0; i < 100000; i++) {
6
    Atomics.add(sharedCounter, 0, 1);
7
  }
8
}
9

10
await Promise.all([increment(), increment()]);
11
console.log(`Final counter value: ${sharedCounter[0]}`);

1
var sharedCounter int32
2

3
func increment(wg *sync.WaitGroup) {
4
  for i := 0; i < 100000; i++ {
5
    atomic.AddInt32(&sharedCounter, 1)
6
  }
7
  wg.Done()
8
}

Locks have costs. Throughput drops because waiters block. Two threads that each hold one lock and then request the other can deadlock and wait forever. Prefer the database's compare-and-swap or a unique constraint when the resource lives in a store that every replica already shares.

Can rate limiting stop concurrent-request abuse?

Rate limiting does not close a race window. An atomic write does. A tight per-identity limit on the redeem or withdraw route still helps: it makes it expensive to spray hundreds of parallel requests at the same object, which is how most limit-overrun probes start.

Put the limit on the business operation, not on "all HTTP." A token bucket keyed on userId (or on the coupon code plus user) with a small capacity is enough to cut the fan-out. Compare algorithms in the rate limiting guide before you pick one.

1
import arcjet, { tokenBucket } from "@arcjet/next";
2

3
const aj = arcjet({
4
  key: process.env.ARCJET_KEY!,
5
  characteristics: ["userId"],
6
  rules: [
7
    tokenBucket({
8
      mode: "LIVE",
9
      refillRate: 2,
10
      interval: 60,
11
      capacity: 4,
12
    }),
13
  ],
14
});
15

16
export async function POST(req: Request) {
17
  const userId = req.headers.get("x-user-id") ?? "anonymous";
18
  const decision = await aj.protect(req, { userId, requested: 1 });
19
  if (decision.isDenied() && decision.reason.isRateLimit()) {
20
    return new Response("Too many redemption attempts.", { status: 429 });
21
  }
22
  // Atomic UPDATE ... WHERE redeemed = false lives here.
23
}

The same limit in Python. Durations are integer seconds here; there is no "1m" string form:

1
from arcjet import Mode, arcjet, token_bucket
2

3
aj = arcjet(
4
    key=ARCJET_KEY,
5
    characteristics=["userId"],
6
    rules=[
7
        token_bucket(mode=Mode.LIVE, refill_rate=2, interval=60, capacity=4),
8
    ],
9
)
10

11

12
async def redeem(request, user_id: str) -> bool:
13
    decision = await aj.protect(
14
        request,
15
        requested=1,
16
        characteristics={"userId": user_id},
17
    )
18
    if decision.is_denied() and decision.reason_v2.type == "RATE_LIMIT":
19
        return False
20
    # Atomic UPDATE ... WHERE redeemed = false lives here.
21
    return True

And in Go, where the interval is a time.Duration. A bare 60 there means 60 nanoseconds, not 60 seconds:

1
var aj, _ = arcjet.NewClient(arcjet.Config{
2
  Characteristics: []string{"userId"},
3
  Rules: []arcjet.Rule{
4
    arcjet.TokenBucket(arcjet.TokenBucketOptions{
5
      Mode:       arcjet.ModeLive,
6
      RefillRate: 2,
7
      Interval:   time.Minute,
8
      Capacity:   4,
9
    }),
10
  },
11
})
12

13
func redeem(w http.ResponseWriter, r *http.Request) {
14
  userID := r.Header.Get("X-User-Id")
15
  if userID == "" {
16
    userID = "anonymous"
17
  }
18

19
  decision, err := aj.Protect(r.Context(), r,
20
    arcjet.WithCharacteristic("userId", userID),
21
    arcjet.WithRequested(1),
22
  )
23
  if err != nil {
24
    slog.Warn("arcjet: protect", "err", err)
25
  }
26

27
  if decision.IsDenied() && decision.Reason.IsRateLimit() {
28
    http.Error(w, "Too many redemption attempts.", http.StatusTooManyRequests)
29
    return
30
  }
31
  // Atomic UPDATE ... WHERE redeemed = false lives here.
32
}

None of these three close the race. They cap how many attempts an identity gets into the window where the race exists, which buys the atomic write room to be the thing that decides.

If two requests still land inside the window, the limiter may allow both. The UPDATE ... WHERE redeemed = false (or the unique constraint) is what makes the second write a no-op. Use both: the limiter shrinks the probe, the atomic write preserves the invariant.

What should you review before you ship a shared write?

1. Name the invariant in one sentence ("a coupon is redeemed at most once").
2. Find the check-then-act pair. If two requests can both pass the check, you have a window.
3. Close it in the store that every replica shares: a conditional update, a unique index, SELECT FOR UPDATE, or an idempotency key with a uniqueness constraint.
4. Use in-process locks only for state that never leaves that process.
5. Add a regression test that fires two concurrent requests and asserts one success.
6. Rate-limit the route so a script cannot cheaply widen the window.

Concurrency makes handlers faster. It also makes "we already checked that" a lie unless you reserved the row. Treat every shared write as a race until the test proves it is not.