Un sito web o un'API possono funzionare perfettamente e non avere vulnerabilità evidenti, ma essere comunque esposti a un problema molto concreto: ricevere troppe richieste in un intervallo di tempo ridotto.
Può succedere durante un attacco automatizzato, quando un bot tenta migliaia di password, quando qualcuno interroga ripetutamente un endpoint oppure quando un'applicazione genera richieste in modo incontrollato.
Per limitare questi comportamenti esiste una misura di sicurezza chiamata rate limiting, utile per proteggere applicazioni web, API e servizi pubblici da richieste eccessive o abusive.
Vediamo come funziona, quali problemi aiuta a prevenire e cosa controllare per capire se un'applicazione è protetta correttamente.
Cos'è il rate limiting?
Il rate limiting è un meccanismo che stabilisce quante richieste un client può effettuare verso un servizio entro un determinato intervallo di tempo.
Per esempio, un'applicazione potrebbe consentire:
- 10 tentativi di accesso in un minuto;
- 60 richieste al minuto per un determinato endpoint API;
- 5 richieste di recupero password ogni 15 minuti;
- un numero massimo di operazioni costose per utente o chiave API.
Quando il limite viene superato, il sistema può rallentare le richieste, rifiutarle temporaneamente o applicare ulteriori controlli.
Non esiste una soglia valida per ogni situazione. Un endpoint pubblico che restituisce dati statici ha esigenze diverse da quello che gestisce pagamenti, invia email o avvia elaborazioni particolarmente onerose.
L'obiettivo non è impedire agli utenti legittimi di utilizzare il servizio, ma rendere più difficile abusarne.
Quali rischi aiuta a prevenire?
Il rate limiting non risolve ogni problema di sicurezza, ma riduce l'efficacia di diversi comportamenti automatizzati.
1. Attacchi brute force
Un attaccante potrebbe provare molte combinazioni di username e password fino a individuare credenziali valide.
Limitare i tentativi di accesso rende questo processo più difficile, soprattutto se il controllo è accompagnato da password robuste, autenticazione multifattore e sistemi di rilevamento dei comportamenti anomali.
È importante evitare limiti troppo semplici: bloccare esclusivamente un indirizzo IP, per esempio, può essere inefficace se le richieste provengono da molti indirizzi differenti.
2. Credential stuffing
Nel credential stuffing vengono utilizzate combinazioni di credenziali provenienti da violazioni precedenti per tentare l'accesso ad altri servizi.
In questo scenario il rate limiting può ridurre il numero di tentativi, ma dovrebbe essere combinato con controlli sul rischio della sessione, MFA e rilevamento degli accessi sospetti.
3. Abuso delle API
Un'API può essere interrogata da software automatizzati molto più rapidamente di quanto farebbe normalmente una persona.
Senza limiti adeguati, un singolo client potrebbe consumare risorse, esaurire quote di utilizzo o generare costi imprevisti.
Il problema è particolarmente importante per gli endpoint che effettuano ricerche complesse, elaborano file o attivano servizi a pagamento.
4. Invio massivo di email e SMS
Endpoint come quelli per la registrazione, la verifica dell'account e il recupero della password possono essere sfruttati per generare grandi quantità di messaggi.
Il rate limiting può limitare gli invii per account, indirizzo destinatario, IP o altra identità tecnica, riducendo il rischio di spam e di costi indesiderati.
5. Esaurimento delle risorse applicative
Alcune richieste richiedono molta più potenza di calcolo rispetto ad altre. Un endpoint che genera report o esegue interrogazioni complesse sul database può diventare un punto critico se viene richiamato continuamente.
Limiti specifici per operazione aiutano a contenere il consumo delle risorse e a mantenere il servizio disponibile per gli altri utenti.
Attenzione: il rate limiting da solo non è una protezione completa contro gli attacchi DDoS distribuiti. Per questi scenari possono essere necessari anche sistemi di mitigazione a livello di rete, reverse proxy, WAF e protezioni del provider.
Come funziona tecnicamente?
Un sistema di rate limiting deve identificare chi sta effettuando le richieste, contare le operazioni e decidere cosa fare quando viene superata la soglia.
La logica può essere basata su diversi elementi:
- indirizzo IP;
- account autenticato;
- API key;
- sessione;
- endpoint richiesto;
- combinazione di più identificatori.
Esistono anche diversi algoritmi. Una finestra temporale fissa è relativamente semplice, mentre una finestra mobile consente un controllo più preciso delle richieste distribuite nel tempo. Altri sistemi utilizzano token bucket o leaky bucket per gestire il traffico in modo più flessibile.
La scelta dipende dal tipo di servizio, dal volume del traffico e dal livello di protezione necessario.
Il codice di risposta HTTP 429
Quando un client supera il limite previsto, il server può restituire lo status HTTP 429 Too Many Requests.
Una risposta può includere informazioni utili per capire quando riprovare:
HTTP/1.1 429 Too Many Requests
Retry-After: 60
Content-Type: application/json
{
"error": "rate_limit_exceeded",
"message": "Troppe richieste. Riprova più tardi."
}
In questo esempio, Retry-After: 60 indica che il client dovrebbe attendere 60 secondi prima di riprovare.
Il comportamento effettivo dipende dall'implementazione: il server può scegliere di comunicare un tempo di attesa diverso oppure applicare altre regole.
È inoltre importante che il client rispetti la risposta, evitando di continuare a inviare richieste senza sosta.
Dove dovrebbe essere implementato?
Il rate limiting può essere applicato in più punti dell'infrastruttura.
Reverse proxy o WAF: permettono di filtrare il traffico prima che raggiunga l'applicazione. Sono utili per applicare regole generali e ridurre le richieste indesiderate.
Applicazione web: consente di definire limiti specifici per singole funzioni, come login, registrazione e recupero password.
Gateway API: centralizza i controlli per le API e può applicare quote differenti in base al client, al piano di utilizzo o alla chiave API.
Servizi interni: possono introdurre limiti ulteriori per proteggere elaborazioni costose e dipendenze esterne.
In un'architettura distribuita è necessario prestare attenzione alla condivisione dei contatori. Se ogni server applicativo mantiene un conteggio indipendente, un client potrebbe superare il limite complessivo distribuendo le richieste tra più istanze.
Come verificare se il rate limiting è configurato correttamente
Una verifica efficace non consiste semplicemente nell'inviare molte richieste e vedere se una viene bloccata. Occorre controllare il comportamento previsto per ogni endpoint rilevante.
Ecco una checklist pratica:
- [ ] Identificare login, recupero password, registrazione e altri endpoint sensibili.
- [ ] Verificare quali limiti sono previsti per gli endpoint API pubblici.
- [ ] Controllare che le richieste eccessive ricevano una risposta appropriata, ad esempio HTTP 429.
- [ ] Verificare che i limiti non possano essere aggirati facilmente utilizzando più sessioni o chiavi API.
- [ ] Controllare che gli indirizzi IP siano interpretati correttamente quando l'applicazione è dietro un reverse proxy.
- [ ] Accertarsi che i limiti siano coerenti con le esigenze degli utenti legittimi.
- [ ] Monitorare i log per individuare picchi anomali e falsi positivi.
- [ ] Testare le regole in un ambiente autorizzato, senza generare traffico che possa compromettere il servizio.
Un errore frequente consiste nel fidarsi di un indirizzo IP ricevuto tramite un header HTTP senza verificare che provenga da un proxy attendibile. Se l'applicazione accetta informazioni di inoltro manipolabili dal client, il controllo basato sull'IP potrebbe diventare inefficace.
Rate limiting e sicurezza: quali sono i limiti?
Il rate limiting è una misura di difesa, non una garanzia di sicurezza.
Non impedisce a un utente autenticato di accedere a dati per cui possiede già permessi eccessivi. Non corregge una vulnerabilità di autorizzazione e non sostituisce la validazione degli input.
Inoltre, limiti troppo rigidi possono penalizzare utenti legittimi, mentre limiti troppo permissivi possono lasciare spazio agli abusi.
La configurazione deve quindi tenere conto del contesto, del costo delle operazioni e dei comportamenti normali dell'applicazione.
Conclusione
Il rate limiting è uno strumento importante per proteggere siti web e API da tentativi ripetuti, automazioni abusive e consumi eccessivi delle risorse. Per essere efficace deve essere configurato in modo coerente con le caratteristiche di ogni endpoint e affiancato ad altre misure di sicurezza.
Con MiHakero puoi analizzare la superficie esposta dei tuoi domini, delle applicazioni web e delle API per individuare configurazioni e problemi di sicurezza rilevabili dall'esterno. È un punto di partenza utile per capire quali aspetti approfondire e dove concentrare le verifiche.