Cosa succede se qualcuno invia al tuo sito migliaia di richieste al secondo? Può tentare di indovinare una password a forza bruta, sovraccaricare il server o esaurirne le risorse. Il rate limiting è la difesa che mette un tetto a tutto questo. Vediamo come.
Resource exhaustion e brute force
Senza limiti, un attaccante può provare combinazioni di password all'infinito (brute force) o semplicemente inondare il sito di richieste finché non cede (resource exhaustion). In entrambi i casi il problema è lo stesso: troppe richieste.
Cos'è il rate limiting
Il rate limiting impone un numero massimo di richieste per un dato periodo, di solito per indirizzo IP. Superata la soglia, le richieste in eccesso vengono rallentate o bloccate temporaneamente.
// es. max 100 richieste ogni 15 minuti per IP
rateLimit({ windowMs: 15 * 60 * 1000, max: 100 });Dove serve di più
- Login e registrazione: per fermare i tentativi a tappeto.
- Form e invii: contro spam e abusi.
- API: per garantire un uso equo delle risorse.
Bilanciare sicurezza e usabilità
I limiti vanno tarati: troppo stretti infastidiscono gli utenti legittimi, troppo larghi non proteggono. La giusta misura dipende dal tipo di sito e di traffico.
Il limite del conteggio per IP
Contare solo per indirizzo IP sbaglia in entrambe le direzioni: dietro un NAT aziendale decine di utenti legittimi condividono lo stesso IP e vengono bloccati insieme, mentre un attaccante su rete mobile o su proxy ne cambia uno ogni pochi minuti. Per questo i tentativi di login si contano anche per account, e dietro un reverse proxy l'IP va letto da X-Forwarded-For solo se il proxy è sotto il tuo controllo: altrimenti è un valore che il client può falsificare.
Collegato: password mai in chiaro e cercare le falle.