# api-fuzzer

Cartographie la surface d'API des trois hôtes preprod (Org, Api,
Blogs) : codes de réponse par endpoint, verbes autorisés (via
`OPTIONS` + en-tête `Allow`), fuites d'information dans les erreurs
500.

## Principe

Lit une liste de chemins dans `endpoints.txt` (modifiable) et, pour
**chaque hôte du périmètre** (`TARGET_BASE_URL` + `TARGET_ALLOWED_HOSTS`),
émet `GET` puis `OPTIONS`. Journalise le code, la taille du corps et
les verbes autorisés.

## Lancement

```bash
./fuzz.sh
# ou avec une liste d'endpoints personnalisée :
./fuzz.sh targets.env mes-endpoints.txt
```

## Sortie

- stdout : endpoints notables (200 accessible, 500 fuite possible).
- `output/api-fuzz.log` : une ligne par test
  (`horodatage \t GET \t base \t code \t taille \t chemin`).

## Actions typiques

- Endpoint renvoyant 500 avec une stack trace → fuite d'info : activer
  `UseExceptionHandler` en prod, masquer les détails.
- `OPTIONS` révèle `DELETE`/`PUT` sur une route qu'on croyait GET-only
  → vérifier l'autorisation côté serveur (les verbes ne devraient pas
  dépendre que du routage).
- Endpoint non documenté en 200 → inventorier et fermer si inutile.