Skipping the line: how bots bypass virtual queues with API replay
How API replay beats the waiting room
A virtual queue is a web page backed by an API: the page polls for position, the API returns a number, and eventually the API issues an entry token. Attackers open the page once, record every API call with a proxy, then script those calls directly. No browser, no rendering, no waiting: just thousands of lightweight HTTP requests minting queue positions in parallel.
The economics are devastating. A real user costs you a full page load and a polling connection; a replayed position costs the attacker a few API calls. At scale, the queue fills with phantom shoppers who will never buy, while real fans watch their position crawl. Your sellout looks instant, your conversion collapses, and the tickets end up listed for resale within minutes.
Why basic defenses miss it
Rate limiting by IP barely registers, because the requests are few per position and spread across proxy networks. CAPTCHAs at entry are bypassed once: the attacker solves one, captures the session, and replays the rest. Device fingerprinting fails because there is no device; it is a script sending HTTP.
Even behavioral bot detection struggles, because the replayed calls are byte-identical to legitimate ones. The requests are not malformed or suspicious in isolation. The fraud is in the aggregate: thousands of sessions that never loaded the page, never rendered anything, and never behaved like a human navigating a queue. You have to look at the journey, not the request.
Binding tokens to real sessions
The fix starts with making each queue position non-transferable. Bind the queue token to the session that earned it: the TLS fingerprint, the device characteristics observed during page load, and a server-side session record. When a replayed request arrives with a valid token but a mismatched session, reject it. The token is only meaningful in the context that created it.
Go further with proof-of-journey: require the client to complete the page's actual JavaScript challenges and record the timing between steps. A real browser takes hundreds of milliseconds to load, render, and poll; a replay script fires calls in microseconds. Server-side, validate that the sequence and timing look like a journey, not a script. Legitimate users pass invisibly; replays fail the physics.
Making positions expensive to fake
Beyond validation, attack the attacker's unit economics. Tie queue entry to something scarce per human: a verified account with history, a phone number with reputation, or a purchase record. Each requirement multiplies the cost of minting fake positions, because now the attacker must farm accounts, not just fire requests.
Add dynamic friction that scales with suspicion. Sessions with thin history get a gentle challenge before entering the queue; sessions that look fully legitimate walk in. The goal is not to challenge everyone but to make the marginal fake position cost more than the marginal real one. When faking positions costs more than the resale margin, the business model dies.
Monitoring the queue itself
Instrument the queue as a fraud surface, not just a traffic tool. Track the ratio of page loads to queue entries: a healthy queue has roughly one entry per load, while a replay attack shows entries with no corresponding loads. Track poll timing distributions, entry-token redemption rates, and the share of positions that convert to purchase.
Set alerts on the anomalies: entry velocity spikes with flat page views, redemption rates collapsing, or geographic clusters of entries with no matching traffic. The queue is where your most valuable moments happen: onsales, drops, releases. It deserves the same fraud monitoring as your checkout, because attackers have already figured out that it is the softer target.