Test d'intrusion d'API
Les API échouent le plus souvent au niveau de l'autorisation, et ces failles ne peuvent pas être trouvées avec un token unique. Nous testons vos API REST et GraphQL sur plusieurs rôles et locataires, en correspondance avec l'OWASP API Security Top 10, pour trouver les lacunes de contrôle d'accès au niveau des objets et des fonctions qui comptent.
Ce que nous testons
Le périmètre s'appuie sur l'OWASP API Security Top 10 (2023). Le travail le plus rentable, et le plus souvent négligé, est le test authentifié sur plusieurs rôles et locataires : c'est le seul moyen de trouver une autorisation défaillante au niveau des objets et des fonctions. Nous demandons votre spécification OpenAPI/Swagger pour couvrir presque toutes les routes (son absence est en soi un constat).
- Broken Object Level Authorization (BOLA / IDOR) entre locataires et entre rôles
- Broken Function Level Authorization (BFLA) via des permutations de rôles et de méthodes
- Autorisation défaillante au niveau des propriétés d'objet : mass assignment et exposition excessive de données
- Authentification, consommation de ressources sans restriction et flux métier sensibles
- Injection, SSRF et mauvaise configuration de sécurité
- Spécificités GraphQL : introspection, batching, DoS par requêtes imbriquées et divulgation d'erreurs
Grey-box, authentifié, multi-rôles
Le grey-box est la norme la plus rentable : vous fournissez la spécification et des comptes de test pour chaque rôle. Le travail est à dominante manuelle, car les scanners détectent les mauvaises configurations et les CVE connues, mais manquent les failles d'autorisation et de logique métier qui constituent l'essentiel du risque API.
- 1
Cadrage & comptes
Nous convenons des limites et collectons plusieurs comptes couvrant les rôles et les locataires, ainsi que votre spécification OpenAPI/Swagger.
- 2
Inventaire des endpoints
À partir de la spécification et du trafic réel, nous cartographions toutes les routes et opérations et signalons les lacunes de la spécification.
- 3
Sondage de l'authentification & de l'autorisation
Nous testons le contrôle d'accès au niveau des objets et des fonctions, sur tous les rôles et locataires. C'est là que se concentre le risque API.
- 4
Abus des entrées, de l'injection & de la logique métier
Nous testons l'injection, la SSRF, la consommation de ressources et l'abus des flux métier sensibles avec preuve de concept.
- 5
Rapport & contre-test gratuit
Vous recevez un rapport priorisé avec des preuves requête/réponse ; nous recontrôlons les points corrigés sans frais supplémentaires, dans le délai fixé par le SoW.
Ce que vous recevez
La même profondeur que dans notre exemple de rapport, dont le constat détaillé est justement un IDOR inter-locataires sur une API (CWE-639, CVSS 3.1). Chaque constat s'accompagne des preuves nécessaires pour le reproduire et le corriger.
- Synthèse à l'attention de la direction et posture de risque globale
- Chaque constat : description, impact, preuve, étapes de reproduction et remédiation
- Preuve de concept sous forme de paires requête/réponse
- Sévérité notée avec CVSS 3.1 et traduite en risque métier
- Références à l'OWASP API Security Top 10 (2023) et au CWE
- Contre-test gratuit des points corrigés dans le délai fixé par le SoW
Ancré dans les standards OWASP API Security
La couverture suit l'OWASP API Security Top 10 (2023) ; le test GraphQL suit en outre OWASP WSTG-APIT-01 (Testing GraphQL). Les constats d'autorisation (BOLA, BFLA, propriétés d'objet) exigent plusieurs comptes répartis sur les rôles et les locataires : un token unique ne permet pas de les trouver. Les constats sont notés avec CVSS 3.1.