# 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

```bash
./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.