Perché un contatore mancante è un rischio
Ogni interfaccia che risponde a richieste — il login, la ricerca, un'API pubblica — può essere chiamata una volta o diecimila. Se nessuno conta, la differenza fra un uso legittimo e un abuso sparisce. Chi vuole forzare una password non la indovina: la prova migliaia di volte al secondo, e se il login non ha un limite, prima o poi ci arriva. Chi vuole i vostri dati non li ruba con un colpo geniale: chiede lo stesso dato per tutti gli identificativi in sequenza, in fretta, finché ha l'archivio. Il limite è ciò che rende questi abusi troppo lenti per valere la pena.
Dove va messo il limite, e dove no
| Dove si mette il limite | Funziona? |
|---|---|
| Nell'app o nel sito che chiama l'API | No: chi abusa non usa la vostra app, chiama l'API direttamente |
| Solo un messaggio «hai fatto troppe richieste» a schermo | No: è di nuovo interfaccia, si aggira |
| Sul server, per ogni chiamante | Sì: è l'unico punto che l'abusante non controlla |
| Sul server, con soglie diverse per operazione | Meglio: il login e un'operazione costosa meritano limiti più stretti |
La regola è la stessa di tutti i controlli di sicurezza: valgono solo se stanno dove chi abusa non può toccarli, cioè sul server.
La verifica, sul vostro sistema
- 01
Scegliete un'interfaccia sensibile
Il login è il candidato classico; un'API costosa o collegata a un servizio a consumo è quello che oggi conta di più.
- 02
Chiamatela molte volte in fretta
Con uno strumento da riga di comando o uno script, ripetete la richiesta molte volte di seguito, sul vostro sistema e con dati di prova.
- 03
Guardate se a un certo punto viene rifiutata
Un server con rate limiting risponde, oltre una soglia, con un rifiuto dedicato (il codice 429, «troppe richieste»). Se accetta tutto senza mai rifiutare, il limite non c'è.