Race Conditions in Web Apps: Double Clicks That Break Rules

Short answer: A race condition happens when two or more requests run at nearly the same time and the result depends on which one finishes first. A web application that checks a rule and then changes data in two separate steps can be fooled into letting both requests pass, for example by using a one-time coupon twice. The fix is to make the check and the change one atomic step, using database constraints, transactions or locks.

What a race condition is

Modern web servers handle many requests simultaneously. Most of the time they work on different things and do not interfere. Trouble starts when two requests touch the same piece of data, and the code does not expect it. The outcome then depends on tiny differences in timing, which is where the name comes from: the requests race each other.

The classic pattern is called check then act. The code first checks a condition, such as whether a coupon has been used, and then acts on it by applying the discount and marking it as used. Between the check and the act, there is a gap. If a second request arrives inside that gap, it also sees an unused coupon and passes the check.

A simple example

A shop offers a gift card with a balance of fifty. A buyer starts two purchases of fifty each at nearly the same moment. Request one reads the balance and sees fifty. Request two also reads it and sees fifty. Both decide that there is enough money, both complete the purchase and both subtract fifty. Depending on how the update is written, the final balance may be zero or even fifty, and the buyer has received goods worth one hundred for the price of fifty.

Nothing in the code looks wrong when you read it line by line. Each request, taken alone, behaves correctly. The flaw appears only when they overlap, which makes it easy to miss in normal testing.

Where race conditions appear

Coupons and vouchers. A one-time code is redeemed many times at once.
Balances and credits. Wallet, gift card and loyalty point systems.
Limits. A rule such as one vote, one free trial or ten uploads per day is exceeded by sending many requests together.
Stock. The last item in stock is sold to several buyers.
Refunds and payouts. A refund is requested several times before the first one is recorded.
Sign-up and verification. The same invitation or e-mail verification link is used more than once.
File handling. A file is checked for safety and then used, and an attacker swaps it in between.
Password reset and login attempts. Rate limits that count attempts in a separate step can be bypassed by parallel requests.

The last example shows why the issue touches security directly. A limit on login attempts is only as strong as the code that counts them, as discussed in brute force protection for logins.

Why a double click is enough

Attackers do not need special skill. Tools can send dozens of requests in the same instant, and some techniques place them in a single network packet so that the server receives them together. A normal visitor can even trigger the problem by accident: a double click on a pay button, a slow connection that causes a retry, or a mobile app that resends a request after a timeout. For this reason, race conditions are as much a reliability problem as a security one. A hardened system makes the same action safe to repeat.

How to prevent them

Make the step atomic. Combine the check and the update into a single database operation. For example, update the coupon to used only where it is currently unused, and look at the number of rows changed. If it is zero, someone else got there first.
Use unique constraints. A database rule that forbids two redemptions for the same coupon and the same order stops duplicates even when the application code fails.
Use transactions with the right isolation. Group the steps so that they succeed or fail together, and choose a level that prevents the conflicting reads.
Lock the resource. Row locks or a short-lived lock in a shared store make competing requests wait their turn.
Use idempotency keys. The client sends a unique key with each action, and the server accepts it only once. Repeats return the original result. This also protects payments and webhooks, as described in webhook security checks.
Update numbers in the database. Use an operation that subtracts from the stored value, instead of reading the value, calculating in code and writing it back.
Disable repeated submission in the interface. It helps with honest double clicks, but it is not a defence, because attackers skip the interface.

How to test for it

Test only systems that you own or have permission to test, and preferably a copy with test data.

Pick actions with limits, such as redeeming a code, applying credit or requesting a refund.
Send several identical requests at the same time, using a testing tool that can run them in parallel.
Check the data afterwards. Was the coupon used once, was the balance correct, was one refund created?
Repeat the test several times, because timing varies and a failure may appear only occasionally.
Add the test to your routine for features that handle money or limits.

Look through your logs for patterns that suggest abuse, such as many successful requests with the same identifier within the same second. The advice in security logging for small sites helps you decide what to record.

Common mistakes

Relying on a read followed by a write, with the logic in between.
Protecting only the visible button and not the server action.
Using a cache as the single source of truth for a limit without atomic updates.
Assuming that a small site is not busy enough for simultaneous requests.
Locking too broadly, which slows the whole site, instead of locking the one resource that needs it.
Checking files first and using them later without protecting them from change.

It also helps to connect this topic to other access problems. A request that changes data it should not touch is a related risk, covered in insecure direct object references, and rate limiting is a layer that reduces the damage of bursts, as explained in rate limiting for websites. None of these replaces correct logic, but together they make exploitation much harder.

What site owners can do without code

If your shop or membership system uses a plugin or a hosted service, you cannot change its internals, but you can still reduce the risk. Choose software from vendors that publish security updates, and keep it current. Ask the vendor how coupons, credits and limits are enforced. Use the built-in setting for usage limits per customer, which many platforms enforce in the database. Review orders for unusual patterns, such as several identical orders at the same time, and set alerts for large refunds. Where possible, hold fulfilment of valuable goods until a payment has been confirmed by the payment provider, not just by the browser.

Teams that build their own features should add one habit to code review: whenever a change reads a value and then writes a value that depends on it, ask what happens if two requests do this together. That single question catches most race conditions before release. For money and limits, also write a small automated test that fires parallel requests and fails the build if the totals are wrong. It costs an afternoon to set up and protects the business for years.

How Site AI Audit helps

Site AI Audit does not test how your code handles simultaneous requests. It checks the visible foundations of your site: the SSL certificate and its expiry, the redirect from HTTP to HTTPS, security headers and exposed software versions, along with SEO, speed and e-mail authentication. The first check is free, covers up to 50 pages and needs no sign-up. You can run a free check of your website or look at the plans for weekly monitoring and alerts.

The bottom line

Race conditions are easy to create and hard to see, because every request looks correct on its own. Make each important step atomic, let the database enforce the rules, use idempotency keys for payments and test with parallel requests. The same habits that stop attackers also protect honest customers from double charges.

GYIK

Is a race condition a type of hacking?

It is a flaw in how software handles timing, and attackers can exploit it. It can also cause errors for normal users, such as a double charge.

Can a small site have this problem?

Yes. Any site where two requests can arrive close together can be affected, especially shops, bookings and membership systems with coupons or limits.

Does disabling the button after a click fix it?

It helps with accidental double clicks, but it does not stop deliberate parallel requests. The server must enforce the rule.

What is an idempotency key?

It is a unique value that the client sends with an action, so the server can recognise repeated requests and return the first result instead of acting again.

How do I know if my plugin is safe?

Check that it is maintained and updated, read its security history and ask the vendor how limits are enforced. Test coupons and credits on a copy of your site.