1.2 KiB
1.2 KiB
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
./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
UseExceptionHandleren prod, masquer les détails. OPTIONSrévèleDELETE/PUTsur 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.