I Applied a Discount Code 20 Times in One Second | Race Condition Story

Lab Link: https://portswigger.net/web-security/race-conditions/lab-race-conditions-limit-overrun

TEJAS

~5 min read · February 16, 2026 (Updated: February 16, 2026) · Free: Yes

Today I solved a lab that taught me something important:

Timing is everything in security.

The lab was: Limit overrun race conditions

And what happened was interesting.

Step 1 — Understanding Before Attacking

Before opening the lab, I learned:

What are race conditions
How they relate to business logic flaws
What is collision
Why timing matters in attacks
How multiple requests at the same time can break logic

This concept was first presented at BlackHat 2023.

Because security testing is not about running tools. It is about understanding timing and logic.

Step 2 — The Lab Challenge

Scenario:

I have $50 in my wallet.

A leather jacket costs $1337.

There is a promo code: PROMO20 (20% discount).

But the code can only be used once per user.

Task: Exploit the race condition to apply the discount multiple times.

Step 3 — Understanding the Logic

Here is how the application works normally:

Request 1:

Submit discount code
Check: Code already used? → False
Apply discount
Mark code as used → True

Request 2:

Submit discount code
Check: Code already used? → True
Reject request

Simple logic. One code. One use.

But what if both requests happen at the same time?

Step 4 — The Race Condition Attack

The idea: Send multiple requests in the same "race window."

If all requests check "code already used" before any of them mark it as used, all requests will pass.

What I did:

Opened Burp Suite
Captured the "Apply coupon" request
Sent it to Repeater
Created a group with multiple tabs (20+ requests)
Sent all requests at once using "Send group (parallel)"

Step 5 — First Attempt: Friday

I tried.

Failed.

The discount code applied once. Then rejected.

I tried different techniques. Different timings. Nothing worked.

I left it.

Step 6 — Second Attempt: Saturday

Tried again.

Failed again.

Still not working.

Left it again.

Step 7 — Third Attempt: Sunday (Today)

I came back fresh.

This time I changed my approach.

Instead of sending 5–10 requests, I sent 20+ requests.

Instead of random timing, I used Burp's "Send group (parallel)" to ensure exact timing.

I reloaded. Tried again. Reloaded. Tried again.

Then it happened.

Step 8 — Lab Solved

Result:

The discount code applied multiple times.

Original price: $1337.00

After discount: $15.40

My wallet: $50.00

Order placed successfully.

Lab solved.

What This Lab Taught Me

1. Race conditions are about timing, not just logic

The application logic was correct. But timing was the vulnerability.

2. Persistence matters

I failed on Friday. Failed on Saturday. Solved on Sunday.

Trying different approaches. Improving techniques. That is how you learn.

3. Race conditions exploit the gap between check and action

The gap between:

Checking if code is used
Marking code as used

That tiny gap is where the attack happens.

4. Not all vulnerabilities are obvious

This is not SQL injection. Not XSS. Not authentication bypass.

This is business logic. This is timing. This is understanding how systems work.

How the Attack Works (Technical Breakdown)

Normal Flow:

Request 1: Check code → Code valid → Apply discount → Mark as used
Request 2: Check code → Code already used → Reject

Race Condition Flow:

Request 1: Check code → Code valid (not marked yet)
Request 2: Check code → Code valid (still not marked)
Request 3: Check code → Code valid (still not marked)
...
Request 20: Check code → Code valid (still not marked)
Then all requests apply discount before marking code as used.

The key: All requests must hit the check before any request completes the action.

For Developers: How to Prevent This

If you are building e-commerce or payment systems, here is what you should do:

Use atomic operations

Ensure check and action happen in a single atomic transaction.

Implement request queuing

Process discount code requests sequentially, not in parallel.

Add rate limiting

Limit how many requests a user can make per second.

Use pessimistic locking

Lock the discount code record during the check-and-apply operation.

Implement idempotency keys

Ensure duplicate requests do not process multiple times.

What I Learned About Learning

This lab was different.

I failed on Friday. I failed on Saturday. I solved on Sunday.

And that taught me something important:

Failing is part of learning.

Every failed attempt taught me something:

How timing works
How Burp's race condition tools work
How to improve my technique

I tried different ways. Different timings. Different approaches.

And finally, it worked.

That is how security testing works.

You fail. You learn. You improve. You solve.

Final Thoughts

Race conditions are one of the hardest vulnerabilities to exploit.

They require perfect timing. They require understanding business logic.

But they exist in real applications. E-commerce sites. Payment gateways. Booking systems.

Anywhere there is a check followed by an action, there is a potential race condition.

This lab taught me to think about timing. Not just logic.

And it taught me persistence.

Try. Fail. Try again. Improve. Solve.

More labs. More learning.

Tools Used:

Burp Suite Professional
PortSwigger Web Security Academy

Next Up: More race condition techniques and timing attacks.

About This Blog

I write all my blogs based on my actual lab-solving experience. I document my thought process, my mistakes, and my learning journey in my own words first. Then I use AI tools (Gemini and Claude) to help organize and structure my writing better — but the content, experience, and learning are 100% mine.