Scalper bots: buying out stock and booking slots
Contents
Share
A scalper bot obtains a good or service of limited availability in a way an ordinary buyer could not do by hand. The OWASP catalog (OAT-005) gives tickets that are later resold for more. The consequence the catalog itself names: the good quickly becomes unavailable to other people. This is not click fraud. A click spends an ad budget; scalping takes a unit from stock or a slot.
If a limited item vanishes in seconds and the orders share the same pattern, start by separating “bought” from “held without payment.”
What counts as scalping
Watching for an item to appear and acting quickly can be part of the event. The catalog separates it from “last second” sniping (OAT-013) and from speeding up a routine on the user’s behalf (OAT-006). An extra sign is that the desired good or service is limited. The named examples include booking tables and rooms, and a bot on slots. How to build such a program is outside this description.
A person who refreshed the page and managed to buy one ticket does not fall under this definition: the method has to be one that cannot be repeated by hand. The disputed edge is speed. The catalog does not translate it into milliseconds. Look at whether the good is limited and whether the action through the application is something a person cannot do by hand.
A cart without payment is a different event
OAT-021 Denial of Inventory is selecting and holding items from a limited stock that are never bought, paid, or confirmed, so other people cannot buy or confirm them. The catalog explicitly separates this from scalping: the attacker does not receive the good or service. The ordinary example is many items in a cart with no move to payment. The same technique is extended to unpaid reservations, slots, queues, and quotas. If server resources are what run out, the catalog points to denial of service, not to scalping.
A cart that holds the whole size is not a resale. It is inventory denial. The controls look similar, the event names differ, and a report that says “we were bought out” on unpaid carts will be wrong.
A queue, a cap, and stock returned
For scalping and inventory holding, OWASP names the first controls:
a queue or waiting room on a limited release;
a per-account purchase cap checked by the server;
holding the item in the cart only until payment, after which stock returns.
The cap should be counted not only by account, but also by repeats of the same payer, address, and device. A number of seconds to hold the item, and a way to fold payment fields together, are not part of this description. A queue does not promise to stop price scraping: it is a control on a scarce release.
One write-up numbers inventory holding differently from the catalog table. What carries into practice is the control — queue, cap, return after non-payment — not the disputed event number.
11% in a report is not the share of your orders
Imperva’s report on 2024 data says about 44% of advanced bot traffic went to APIs and about 10% to web applications. In the breakdown of bot attacks on APIs, scalping is about 11%, beside data collection at about 31%, payment fraud at about 26%, and account takeover at about 12%. Scalping is described there as quickly buying or reserving a large volume of scarce goods and services. The percentages are shares in a breakdown of API attacks on the vendor’s customer network. They are not the share of your shop’s orders.
What to do on a scarce item:
Separate a purchase a person cannot repeat by hand from a cart or booking left unpaid.
Put a queue on a limited release.
Check the unit cap on the server: by account, payer, address, and device, not only with a field in the browser.
Return stock if payment does not complete.
Do not carry the 11% from the report onto your revenue. Who clicks ads, click fraud versus sklikivanie, invalid clicks, and a Yandex refund are not decided by this cap: an ad click and a unit in stock are charged in different systems.
Walk one limited release through the OWASP controls without adding seconds the description does not have. First a queue or a waiting room: a person and an automated client stand in one release, not in a race to refresh the page. Then a unit cap on the server. The server counts the cap, and not only by account: repeats of the same payer, address, and device are part of the same cap. Then the cart. The item is held until payment and returns to stock if payment does not happen. That closes inventory denial, where the attacker does not receive the unit. The queue still does not promise to stop price copying: scraping is a different event.
Write down separately what you would see if you opened the Imperva report beside this. About 11% scalping is a share in a breakdown of bot attacks on APIs across that network’s customers for 2024, beside about 31% data collection, 26% payment fraud, and 12% account takeover. About 44% of advanced bot traffic in the same report went to APIs and about 10% to web applications. None of those figures is a share of your orders. If 40 tickets out of 40 sold overnight, that is your stock, not “11%.”
A person who bought one ticket by hand does not fall under OAT-005: the method has to be one that cannot be repeated by hand. The catalog does not translate a fast refresh into milliseconds. Look at whether the good is limited and whether it was obtained. Call unpaid slots inventory denial. If server memory and processes are what ran out, that is denial of service, and scalping is not the name for it.