Aller au contenu principal
Expert Cybersécurité & IAv9.0
Centres de ressources conformité
Besoin d'un accompagnement expert ?
Devis personnalisé sous 24h — audit, conformité, incident
Checklists Sécurité — Audit & Durcissement
Formats disponibles
📄 PDF 📊 Excel 🌐 Web

11 checklists professionnelles couvrant 2 200+ points de contrôle. Téléchargement gratuit, aucune inscription.

REST API Fuzzing

devsecops

Définition

Le REST API Fuzzing (fuzzing d'APIs REST) est une technique de test de sécurité dynamique qui consiste à générer et envoyer automatiquement des milliers de requêtes avec des données inattendues, malformées, ou aléatoires vers une API REST pour découvrir des comportements non anticipés, des vulnérabilités de sécurité (injections, débordements, plantages), et des erreurs de gestion des cas limites. Le fuzzing est une approche automatisée complémentaire aux tests manuels et aux tests basés sur des cas de test prédéfinis. Le fuzzing d'API REST se distingue du fuzzing web classique par sa connaissance du format attendu des requêtes : en s'appuyant sur la spécification OpenAPI (Swagger) de l'API, les fuzzers d'API peuvent générer des mutations intelligentes des requêtes conformes au format attendu (valeurs string trop longues, entiers négatifs là où des positifs sont attendus, types incorrects, champs obligatoires manquants) plutôt que des données purement aléatoires. Cette approche "smart fuzzing" découvre plus rapidement des vulnérabilités d'application tout en réduisant le bruit. Les outils de REST API Fuzzing incluent : RESTler (Microsoft Research — génère automatiquement des séquences de requêtes depuis une spec OpenAPI, en tenant compte des dépendances entre endpoints), Schemathesis (Python — génère des tests basés sur les schémas OpenAPI/GraphQL avec Property-Based Testing via Hypothesis), Dredd (validation de conformité de l'API à sa spécification, et découverte des cas non couverts), CATS (Contract Aware Tests) — génère des tests de fuzzing d'API en Java, et OWASP ZAP avec ses extensions de fuzzing pour les APIs REST. Les types de mutations testées par les fuzzers d'API incluent : les valeurs limites (entiers MIN_INT/MAX_INT, chaînes vides, très longues, null), les injections (SQL, XSS, SSTI via les paramètres), les types incorrects (envoi d'un array où une string est attendue), les champs supplémentaires non documentés (mass assignment test), les requêtes dans un ordre inattendu (tester les pre-conditions manquantes), et les séquences de requêtes exploitant des relations entre ressources (créer puis supprimer puis accéder à une ressource supprimée).

Fuzzing basé sur OpenAPI avec Schemathesis

Schemathesis est l'outil de fuzzing d'API REST le plus adapté à l'intégration CI : pip install schemathesis && schemathesis run https://api.example.com/openapi.json --checks all --report=schemathesis-report.html. Il génère automatiquement des cas de test depuis la spec OpenAPI (mutations de types, valeurs limites, cas négatifs), exécute ces tests contre l'API réelle, et rapporte les cas où l'API retourne des réponses inattendues (erreurs 500, comportements non conformes à la spec). L'option --auth 'Bearer token' permet le fuzzing authentifié.

RESTler : fuzzing de séquences d'API

RESTler (Microsoft Research) est unique par sa capacité à fuzzer des séquences de requêtes en tenant compte des dépendances entre endpoints : l'ordre POST /users → GET /users/{id} → DELETE /users/{id} est découvert automatiquement depuis la spec OpenAPI. RESTler génère des séquences valides et invalides, testant notamment : l'accès à des ressources appartenant à d'autres utilisateurs (BOLA), les transitions d'état invalides, et les conditions de race sur la création/suppression de ressources. Cette capacité de fuzzing stateful le distingue des fuzzers d'API traditionnels stateless.

Intégration du fuzzing d'API dans le pipeline CI

Le fuzzing d'API dans le CI nécessite un équilibre entre couverture et durée : un fuzzing "rapide" (10-30 min, mutations de base, quelques milliers de requêtes) à chaque PR, et un fuzzing "profond" (2-4h, mutations étendues, fuzzing stateful) exécuté nuitamment ou sur des branches de release. Les résultats du fuzzing (requêtes déclenchant des 500, comportements inattendus, réponses non conformes à la spec) sont convertis en cas de test de régression pour prévenir les régressions futures. Les outils de fuzzing modernes génèrent automatiquement ces cas de test.

Articles liés

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis