The floating pat-down: why your app's security is mostly theatre

If you run a site that sells tickets, drops limited stock, or handles any kind of high-demand sale, you already know what happens when too many people show up at once. 

The site falls over, real customers get error pages, and bots quietly hoover up whatever's on sale. 

A virtual waiting room is the standard fix: when demand spikes, CrowdHandler holds visitors in an orderly queue and feeds them through at a rate your infrastructure can actually handle, so the site stays up and everyone gets a fair shot. 

That works fine when the waiting room sits in front of your whole site. The problem is that modern apps increasingly aren't built that way, and a lot of them are protected in a way that looks solid and isn't. 

The wand that never beeps

You know the security patdown. The bouncer pats you down, you nod at each other, and you walk through. Nothing was actually checked. That’s how most web apps work: lots of motion, no real contact.

Why does everyone build this way?

So, the modern stack splits cleanly in two. 

1. There's a front-end, usually static or server-rendered.

2. There's an API sitting off to the side, often on its own domain and sometimes in a completely separate cloud.

This is now the default. Next.js, Nuxt, Remix, SvelteKit and Astro all encourage it. Headless commerce platforms ship it to you pre-divided, a hosted storefront in one hand and a public API in the other, with the plumbing left as an exercise for the reader. 

Host the front-end on Vercel, Netlify or Cloudflare Pages, and you've got the model nearly every e-commerce and ticketing build wears in 2026: a fast, mostly-static front-end and an API doing all the real work somewhere else.

Great for developer experience. Great for page speed. However, it’s where the security model fails.

Why the front-end is a husk

The front-end is featherweight. It's markup, scripts and a bit of styling, and you could fire half the internet at it without it flinching, because there's almost nothing there to overwhelm.

Every expensive, fragile, this-is-where-it-hurts action lives on the API. So if your waiting room is wrapped around the static site while your API answers cross-domain calls on its own address, you've protected the bit that was never going to fall over and left the bit that does fall over wide open. 

Customers come through the guarded entrance. Trouble walks in through a side door nobody's watching.

We run into this constantly: SPAs and SPA-shaped apps built exactly this way. Plenty of people would honestly rather not know, and when nothing's broken yet, there's a logic to leaving the stone unturned. 

The teams who'd rather see it clearly want one waiting room stretched across both halves, not a shield guarding only the harmless one.

We've got two well-tested ways to do that.

Strategy 1: proxy the API through your main domain

The neatest option, when you can swing it, is to stop treating the API as a separate address at all. Route its calls back through your main domain and put one shield in front of the lot, whether that's CrowdHandler, Cloudflare or whatever's already in play.

Do that, and the lightweight front-end finally speaks for the whole system. A DDoS attempt gets a queue position. An API call that skips the happy path gets a queue position. The attacker waits in line behind your real customers, same as anyone. If your architecture has room to bend this way, reach for this first.

Strategy 2: edge workers in front of the critical endpoints

When it won't bend, you go surgical. Edge workers dropped in front of the API at the one or two spots that carry the weight.

In a shop that's nearly always the add-to-cart call, and the reasoning is worth spelling out. Checkout is impossible without it, so it's the obvious gate. However, it's also dangerous on its own terms, because someone who can only add to the art can still ruin the experience for genuine shoppers without ever buying a single item. 

That's the classic ticket-bot move: stuff inventory into carts so real buyers can't reach it, then sell the access on, or release and re-grab it round and round.

The worker handles this by checking in with the CrowdHandler API and tallying hits against the product ID, treating them as though they'd landed on whatever page normally triggers the call, typically the product detail page. Haven't legitimately queued for that page? Then the API call doesn't happen for you.

There's a quiet upside to mounting the worker right there. It's sitting directly on the genuine bottleneck, the API rather than the static site, which means our autotune can read the surface that actually strains and let people through at a rate that reflects reality. 

Watch only the host site, and you're staring at a component that essentially never sweats, which is tuning blindfolded. Moreover, because that host site does so little, its side of the integration stays trivial: a touch of JavaScript to move people aside on demand, while every bit of real validation and pacing happens down at the API.

The trap only works if every part holds

There's one rule you cannot skip, and it's the part people drop: kill the session the moment someone checks out.

Once an visitor has paid, that session has to die, so it can't be dusted off for round two. Leave it alive, and a capable bot queues exactly once, then transacts on a loop forever. Enforce it, and you've stripped that option away, forcing the attacker to behave like an ordinary happy-path buyer every single time, through the queue, through the product page, through the validated call. 

The trap only catches anything if every piece holds. One slack component, and the whole thing snaps shut on empty air.

You don't need to rewrite your app.

To be clear about the scope, this is not a rebuild. Mostly it's loading and adjusting edge workers we already make and maintain, with versions ready for:

• AWS CloudFront 

• Cloudflare 

• Netlify

• Akamai

You're guarding one or two endpoints, not touching your core code. We've done this quietly for a long list of customers across a long list of stacks, and it's the same mechanism humming away beneath our Shopify integration.

When this is worth a conversation

If something at the back of your mind keeps muttering that your setup's a bit more exposed than you'd say out loud, talk to us. Even if a traditional queue feels like overkill for you, this is how you get graceful rate limiting and DDoS cover built into the parts of your app that genuinely give way, and not the parts that never even flinch.

Need some extra security? Sign up to CrowdHandler for free.