36 lines
No EOL
1.2 KiB
Markdown
36 lines
No EOL
1.2 KiB
Markdown
# 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. |