Approche
Le schéma d'abord, l'autorisation ensuite
Une API GraphQL expose souvent bien plus que prévu via l'introspection du schéma — champs, mutations, relations entre types, parfois même en environnement de production. Je commence systématiquement par vérifier si l'introspection est accessible sans authentification, avant d'auditer chaque requête et mutation pour des problèmes de référence directe non sécurisée et d'autorisation incohérente entre les champs.
C'est un point que je retrouve régulièrement en reconnaissance : des schémas GraphQL entiers accessibles sans authentification, révélant la structure interne de l'application à qui sait demander.
Cas emblématiques
Le type de faille recherchée ici
Peloton — données privées exposées via l'API GraphQL
En 2021, l'API GraphQL des vélos connectés Peloton exposait les données de profil (y compris marquées « privées ») de n'importe quel utilisateur à quiconque connaissait son ID, sans contrôle d'accès — découvert et divulgué par Pen Test Partners.
Shopify — énumération de données via batching de requêtes
Un rapport de bug bounty public a montré que l'API GraphQL de Shopify permettait, via le batching de requêtes, de contourner les limites de taux et d'énumérer des données marchandes normalement protégées.
Introspection activée par défaut en production
Un schéma GraphQL introspectable expose l'intégralité du modèle de données, des mutations disponibles et des champs internes à un attaquant non authentifié — un classique retrouvé sur de nombreuses API en production.
Déni de service par requête imbriquée profonde
Sans limite de profondeur ni de complexité, une requête GraphQL imbriquée récursivement peut multiplier exponentiellement la charge sur le serveur — documenté comme vecteur de DoS par l'OWASP GraphQL Cheat Sheet.
Contournement d'autorisation par alias de champs
L'utilisation d'alias GraphQL pour dupliquer un même champ dans une requête permet de contourner certaines implémentations naïves de rate-limiting ou de contrôle d'accès basées sur le nom du champ.
IDOR via mutation non vérifiée côté serveur
Une mutation GraphQL qui accepte un identifiant de ressource sans revérifier la propriété côté serveur permet de modifier ou supprimer des données appartenant à un autre utilisateur — variante GraphQL de l'IDOR classique.
Autres prestations
Prêt à savoir ce qu'un attaquant verrait de vous ?
Discutons de votre application, de votre calendrier, et de ce qu'un test d'intrusion peut couvrir.