security-tools/tools/rate-limit-probe/README.md

rate-limit-probe

Mesure si l'endpoint d'authentification (ou tout endpoint sensible) de la preprod met en place un rate-limiting / verrouillage contre le bruteforce.

Principe

Envoie RATE_PROBE_COUNT requêtes (20 par défaut) avec un mauvais mot de passe sur LOGIN_PATH et observe les codes de réponse :

• 429 → rate-limiting actif (bon). Le seuil (après combien de requêtes) se lit dans le journal.
• changement soudain de code (ex : 401 → 403/423) → verrouillage (lockout) après N échecs.
• rien de tout ça (toujours 401/400) → AUCUN rate-limit : vulnérabilité, le bruteforce n'est pas freiné.

Lancement

./probe.sh

Paramètres (dans targets.env) :

• RATE_PROBE_COUNT — nombre de requêtes (défaut 20).
• RATE_PROBE_DELAY — délai entre requêtes en secondes (0 = rafale ; pour tester le rate-limit on veut justement une rafale, mais gardez un count modéré).

Sortie

• stdout : verdict (rate-limit actif / lockout / absent).
• output/rate-limit.log : horodatage \t n/N \t code.

Actions typiques

• Aucun rate-limit → en ajouter un au reverse proxy (ex : limit_req nginx) ou côté application (bucket par IP+utilisateur).
• Rate-limit trop agressif (429 dès la 2e requête) → risque de bloquer les légitimes ; ajuster le seuil.