Se gestisci un sito che vende biglietti, mette in vendita prodotti in edizione limitata o gestisce qualsiasi tipo di vendita molto richiesta, sai già cosa succede quando si riversano troppe persone tutte insieme.
Il sito va in tilt, i clienti reali si ritrovano davanti a pagine di errore e i bot fanno man bassa in silenzio di tutto ciò che è in vendita.
Una sala d'attesa virtuale è la soluzione standard: quando la domanda aumenta improvvisamente, CrowdHandler mantiene i visitatori in una coda ordinata e li fa accedere al sito a una velocità che la vostra infrastruttura è effettivamente in grado di gestire, in modo che il sito rimanga attivo e tutti abbiano le stesse opportunità.
Questo funziona bene quando la "sala d'attesa" si trova all'ingresso del sito. Il problema è che le app moderne sempre più spesso non sono costruite in questo modo, e molte di esse sono protette con un sistema che sembra solido ma in realtà non lo è.
La bacchetta che non mai
Conosci bene la perquisizione di sicurezza. Il buttafuori ti perquisisce, vi scambiate un cenno di intesa e puoi passare. In realtà non è stato controllato nulla. È così che funzionano la maggior parte delle applicazioni web: tanto movimento, nessun contatto reale.
Perché tutti costruiscono in questo modo?
Quindi, lo stack moderno si divide nettamente in due.
- C'è un front-end, solitamente statico o renderizzato dal server.
- C'è un'API che si trova un po' in disparte, spesso su un dominio a sé stante e talvolta in un cloud completamente separato.
Ormai è l'impostazione predefinita. Next.js, Nuxt, Remix, SvelteKit e Astro lo raccomandano tutti. Le piattaforme di e-commerce headless lo forniscono già suddiviso: da un lato un negozio online ospitato e dall'altro un'API pubblica, lasciando al lettore il compito di occuparsi dell'integrazione.
Ospita il front-end su Vercel, Netlify o Cloudflare Pages e avrai il modello adottato da quasi tutte le piattaforme di e-commerce e di vendita biglietti nel 2026: un front-end veloce e prevalentemente statico e un’API che svolge tutto il lavoro vero e proprio altrove.
Ottimo per l'esperienza degli sviluppatori. Ottimo per la velocità delle pagine. Tuttavia, è proprio qui che il modello di sicurezza fallisce.
Perché il front-end è solo un
Il front-end è leggerissimo. È composto da markup, script e un po' di styling, e potresti scaricarci sopra metà di Internet senza che batta ciglio, perché non c'è praticamente nulla che possa sovraccaricarlo.
Ogni operazione costosa, delicata e "critica" risiede nell'API. Quindi, se la tua "sala d'attesa" è integrata nel sito statico mentre la tua API risponde alle chiamate cross-domain dal proprio indirizzo, hai protetto la parte che non avrebbe mai potuto andare in crash e hai lasciato completamente esposta quella che invece va in crash.
I clienti entrano dall'ingresso sorvegliato. I guai entrano da una porta laterale che nessuno controlla.
Ci capita continuamente: SPA e app di tipo SPA realizzate proprio in questo modo. Molte persone, onestamente, preferirebbero non saperlo, e finché tutto funziona, c’è una certa logica nel non andare a scavare troppo a fondo.
Le squadre che preferiscono vedere le cose chiaramente vogliono una sala d'attesa che si estenda su entrambe le metà campo, non uno scudo che protegga solo quella innocua.
Abbiamo due metodi collaudati per farlo.
Strategia 1: utilizzare proprio principale come proxy per l'API#
La soluzione migliore, se te lo puoi permettere, è smettere del tutto di considerare l'API come un indirizzo separato. Reindirizza le sue chiamate attraverso il tuo dominio principale e metti un unico filtro a proteggere il tutto, che si tratti di CrowdHandler, Cloudflare o qualsiasi altra soluzione tu stia già utilizzando.
Se lo fate, il front-end leggero finirà per rappresentare l’intero sistema. Un tentativo di attacco DDoS ottiene una posizione nella coda. Una chiamata API che non segue il percorso normale ottiene una posizione nella coda. L’autore dell’attacco aspetta in coda dietro ai vostri clienti reali, proprio come chiunque altro. Se la vostra architettura offre la possibilità di adattarsi in questo modo, puntate prima di tutto su questa soluzione.
Strategia 2: posizionare i lavoratori periferici davanti agli endpoint critici
Quando non si piega, bisogna ricorrere a un intervento "chirurgico". Gli operai hanno fatto cadere il bordo davanti all'API proprio nei punti in cui si concentra il peso.
In un negozio, quasi sempre il pulsante "Aggiungi al carrello" funge da punto di accesso, e vale la pena spiegarne il motivo. Senza di esso, non è possibile procedere al checkout, quindi rappresenta il punto di accesso ovvio. Tuttavia, è anche pericoloso di per sé, perché chi può solo aggiungere articoli al carrello può comunque rovinare l'esperienza degli acquirenti autentici senza mai acquistare un singolo articolo.
È la classica mossa dei bot per i biglietti: riempire i carrelli di prodotti in modo che gli acquirenti reali non possano accedervi, per poi rivendere l’accesso, oppure rilasciare i prodotti e riacquistarli, in un ciclo che si ripete all’infinito.
Il sistema gestisce questa situazione effettuando una verifica tramite l'API CrowdHandler e conteggiando gli accessi in base all'ID del prodotto, trattandoli come se fossero stati effettuati dalla pagina che normalmente attiva la chiamata, in genere la pagina dei dettagli del prodotto. Non sei stato legittimamente inserito nella coda per quella pagina? In tal caso, la chiamata all'API non verrà effettuata per te.
C'è un vantaggio discreto nel posizionare il worker proprio lì. Si trova direttamente sul vero e proprio collo di bottiglia, ovvero l'API anziché il sito statico, il che significa che il nostro sistema di ottimizzazione automatica può rilevare il carico effettivo e consentire l'accesso agli utenti a una velocità che riflette la realtà.
Se ti concentri solo sul sito host, ti ritrovi di fronte a un componente che praticamente non fa mai alcuno sforzo: è come effettuare una messa a punto ad occhi chiusi. Inoltre, dato che il sito host svolge così poche operazioni, la sua parte nell'integrazione rimane banale: basta un po' di JavaScript per spostare gli utenti su richiesta, mentre ogni aspetto concreto della convalida e della gestione dei tempi avviene a livello dell'API.
La trappola funziona solo se ogni parte
C'è una regola che non puoi ignorare, ed è proprio quella che molti trascurano: chiudi la sessione non appena qualcuno esce dal sito.
Una volta che un visitatore ha effettuato il pagamento, quella sessione deve terminare, in modo che non possa essere riutilizzata per un secondo tentativo. Se la si lascia attiva, un bot ben programmato si inserisce in coda esattamente una volta, per poi eseguire la transazione in loop all’infinito. Applicando questa regola, si elimina tale possibilità, costringendo l’autore dell’attacco a comportarsi ogni singola volta come un normale acquirente che segue il percorso standard: passando per la coda, la pagina del prodotto e la richiesta convalidata.
La trappola cattura qualcosa solo se ogni suo elemento è ben saldo. Basta un solo componente allentato e l’intera struttura si chiude di colpo sul nulla.
Non è necessario riscrivere tua
Per chiarire bene la portata dell'intervento, non si tratta di una ricostruzione. Si tratta principalmente di caricare e mettere a punto gli edge worker che già realizziamo e gestiamo, con versioni pronte per:
- AWS CloudFront
- Cloudflare
- Netlify
- Akamai
Ti occupi di proteggere uno o due endpoint, senza toccare il codice principale. Lo abbiamo fatto in modo discreto per una lunga lista di clienti su una vasta gamma di stack, ed è lo stesso meccanismo che lavora silenziosamente alla base della nostra integrazione con Shopify.
Quando vale la pena parlarne
Se una vocina nella tua testa continua a sussurrarti che la tua configurazione è un po’ più vulnerabile di quanto ammetteresti ad alta voce, rivolgiti a noi. Anche se una coda tradizionale ti sembra una misura eccessiva, è così che otterrai una limitazione di velocità elegante e una protezione DDoS integrate proprio nelle parti della tua app che sono realmente a rischio, e non in quelle che non battono ciglio.
Hai bisogno di maggiore sicurezza? Iscriviti gratuitamente a CrowdHandler.