Una web app aziendale che espone delle API — per un’integrazione con un gestionale, per un’app mobile o per un partner esterno — prima o poi si scontra con lo stesso problema: cosa succede quando qualcuno fa troppe richieste? Può essere un bug in un client, uno script mal scritto, un tentativo di scraping o, nei casi peggiori, un attacco. Senza rate limiting, ogni web app è esposta a sovraccarichi che possono rallentarla o mandarla offline per tutti gli utenti, non solo per chi sbaglia.
Quando sviluppo applicazioni web per i miei clienti — che si tratti di un gestionale come tandemops.app o di una piattaforma con API pubbliche come apicco.app — il rate limiting non è un dettaglio tecnico da aggiungere “se avanza tempo”: è parte dell’architettura fin dal primo giorno, esattamente come l’autenticazione o la validazione degli input.
Perché un’API senza limiti è un rischio per l’azienda
Un’API aziendale senza controlli di frequenza è vulnerabile a diversi scenari concreti:
- Sovraccarico involontario: un client interno con un bug in un ciclo che richiama l’API migliaia di volte al minuto.
- Scraping e abusi: bot che raccolgono dati (prezzi, contenuti, contatti) a ritmo continuo, consumando risorse server senza alcun beneficio per l’azienda.
- Credential stuffing e brute force: tentativi automatizzati di indovinare password o token, che senza limiti possono essere ripetuti all’infinito.
- Denial of service applicativo: richieste “pesanti” (ricerche complesse, esportazioni, generazione di PDF) ripetute in rapida successione fino a saturare CPU o database.
In tutti questi casi il danno non colpisce solo chi genera il traffico anomalo, ma tutti gli altri utenti della web app, che vedono tempi di risposta più lenti o, nei casi peggiori, un servizio non disponibile. Per un’azienda che dipende da quell’applicazione per lavorare — gestire prenotazioni, emettere documenti, coordinare un team — è un problema operativo, non solo tecnico.
Come funziona il rate limiting: le tecniche che uso
Token bucket e sliding window
Le due strategie più affidabili per limitare la frequenza delle richieste sono il token bucket e la sliding window. Nel token bucket, ogni client ha a disposizione un “secchio” di token che si ricarica a un ritmo costante: ogni richiesta consuma un token, e quando il secchio è vuoto le richieste vengono rifiutate o messe in coda finché non arrivano nuovi token. È un meccanismo che permette picchi brevi di traffico legittimo senza penalizzare l’utente normale, ma blocca chi martella l’API in modo continuo. La sliding window, invece, conta le richieste in una finestra temporale mobile (ad esempio “non più di 100 richieste negli ultimi 60 secondi”), offrendo un controllo più preciso rispetto alle finestre fisse.
Limiti a più livelli
Un’implementazione solida non applica un limite unico, ma livelli diversi a seconda del contesto: per indirizzo IP, per utente autenticato, per API key o per endpoint. Un endpoint di login, ad esempio, merita un limite molto più stringente di un endpoint di sola lettura, perché è il bersaglio tipico dei tentativi di forzatura degli accessi.
Lo stack tecnico: Nginx, Redis e application layer
Nelle infrastrutture che gestisco su HestiaCP e con Docker, il rate limiting viene applicato su più strati, che si completano a vicenda:
- Nginx, come reverse proxy davanti alle applicazioni, applica un primo filtro con la direttiva
limit_req_zone, bloccando il traffico anomalo prima ancora che raggiunga il backend: è il modo più efficiente per assorbire picchi grossolani con un costo minimo in termini di risorse. - Redis è la scelta naturale quando serve un rate limiting distribuito e preciso a livello applicativo: essendo in memoria e condiviso tra più istanze dell’app, permette di contare le richieste per utente o per API key in tempo reale, anche quando la web app gira su più container Docker in parallelo.
- Application layer: nel codice backend (Node.js, PHP o altri linguaggi a seconda del progetto) implemento middleware dedicati che restituiscono risposte HTTP corrette — status
429 Too Many Requests, con headerRetry-After— così che i client, umani o automatici, sappiano esattamente quando riprovare.
Questa combinazione — filtro grossolano a livello di proxy, conteggio preciso e distribuito con Redis, logica fine nell’applicazione — è lo stesso approccio a strati che uso per la sicurezza in generale: nessun singolo meccanismo deve essere l’unica linea di difesa.
Rate limiting e user experience: non è solo “bloccare”
Un errore comune è pensare al rate limiting solo come un muro. Fatto bene, è anche uno strumento di esperienza utente: risposte chiare quando si è vicini al limite, header che comunicano quante richieste restano disponibili, limiti differenziati per piani o tipi di account (ad esempio più margine per i clienti su un piano superiore). In un’app come apicco.app, dove le API vengono usate da integrazioni esterne, questo significa che i partner tecnici possono progettare i loro sistemi sapendo esattamente quali sono le regole, invece di scoprirlo a errori avvenuti.
Cosa significa per la tua azienda
Se la tua azienda ha una web app, un gestionale o un’API che espone dati a clienti, partner o app mobile, il rate limiting non è un optional: è ciò che garantisce che il servizio resti stabile e prevedibile anche quando il traffico non è quello previsto — che sia un picco di successo o un tentativo di abuso. È lo stesso principio che applico quando penso a l’intera infrastruttura che gestisco per i miei clienti: hosting su HestiaCP, container Docker isolati, certificati SSL sempre validi, e ora anche protezioni di frequenza sulle API, tutto pensato perché il sistema regga nel tempo senza sorprese.
Sviluppiamo insieme la tua applicazione
Progetto e sviluppo applicazioni web e API su misura, dall’architettura alla messa in produzione, incluse le protezioni — come il rate limiting — che spesso fanno la differenza tra un sistema che regge sotto pressione e uno che si blocca al primo imprevisto. Se la tua azienda ha bisogno di una web app affidabile, di un’API sicura o semplicemente di qualcuno che segua l’intero ciclo di vita del progetto, contattami per parlarne: puoi vedere alcuni dei progetti che ho realizzato e gestisco tuttora su cornelcaba.com.
