Home / Knowledge hub / Limit overrun
Knowledge hub
Limit overrun
Exceeding a cap, such as one redemption per customer, with parallel requests.
What it means
A limit overrun happens when an application enforces a cap, such as one redemption per customer or a daily withdrawal limit, but a burst of simultaneous requests all pass the check before any of them records its use. Each request sees the counter at zero, so each is allowed.
The cap itself is usually written correctly. The flaw is the gap between checking the count and updating it. This is a form of race condition, and the weakness is catalogued by MITRE as a time-of-check to time-of-use problem. Ten requests sent in the same instant can do what one request, sent politely, never could.
Why it matters
The cost lands wherever a cap protects money or stock. A single-use voucher applied five times, a free-tier quota exceeded, a withdrawal that goes through twice, or an invitation accepted by several accounts. None of it looks like an attack in the logs, because each request was individually valid.
It also undermines the controls built on top. A rate limit that counts requests after the work is done, or a coupon rule that reads before it writes, will not hold under a parallel burst. Finance usually spots it first, when reconciliation shows more redemptions than customers.
How it shows up
You meet it in coupon and gift-code redemption, referral rewards, wallet and balance transfers, seat and stock reservation, and any free allowance. The tell-tale code reads a value, decides, then writes it back as three separate steps, often in a handler that runs on many workers at once.
The fix belongs in the data layer. Make the check and the update one atomic operation, use a unique constraint so a second insert fails, or lock the row for the duration. Do not rely on a flag held in application memory. To test, send the same request many times at once and compare the result with what one request would allow.
Questions people ask
Limit overrun, answered
Is a limit overrun the same as a race condition?
A limit overrun is one common outcome of a race condition. The wider term covers any bug where timing between steps changes the result. A limit overrun is the specific case where that timing lets someone get past a cap that should have held.
Does rate limiting stop it?
Not reliably. Rate limiting restricts how often a client can call you over time, while a limit overrun needs only a handful of requests landing together. Many limiters also count after the work is done, so the burst is already through. The cap needs to be enforced where the data is written.
How do we test for a limit overrun?
Pick an action with a cap, then send many identical requests at the same moment, ideally over one connection or timed to arrive together. Check how many succeeded and whether the stored counter matches. More successes than the cap allows is a confirmed finding, and the responses are your evidence.
Which fix is best: locks or unique constraints?
A unique constraint is simplest when the rule is one per customer, because the database refuses the duplicate itself. For counters and balances, use an atomic conditional update or a row lock. Either way, the decision and the write must happen as one step.
Can a scanner find limit overruns?
Rarely. A scanner does not know which actions carry a cap or what the cap should be, so it cannot judge whether a burst broke it. It takes a test that understands the rule, fires the burst, and checks the outcome against what the rule allows.
Related
Terms that sit next to this one
Race condition
Two near-simultaneous actions producing a result neither should allow.
Time of check to time of use
A gap between checking a condition and acting on it that an attacker can use.
Coupon abuse
Using a discount code more times, or in more ways, than you intended.
Double spend
Using the same balance, credit or voucher twice by acting faster than your checks.
Rate limiting
Capping how often something can be attempted, per user or per address.
What happens when requests arrive together?
Caps on coupons, credits, balances and invitations are a business rule worth testing under a burst, not one request at a time. We send the burst and report only what got through, with the requests. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.