API GraphQL : 6 vulnérabilités que les scanners ne détectent pas

> En bref : Introspection activée, attaques en profondeur, batching, IDOR via relay IDs : les failles GraphQL invisibles aux outils automatisés.

GraphQL : flexibilité pour les développeurs, surface d'attaque pour les attaquants

GraphQL a remplacé REST dans de nombreuses applications modernes. Sa flexibilité est son plus grand atout : et sa plus grande faiblesse. Les scanners de vulnérabilités classiques, conçus pour REST, passent à côté de 6 catégories de failles spécifiques à GraphQL.

Vulnérabilité 1 : Introspection activée en production

L'introspection permet à quiconque de découvrir l'intégralité de votre schéma : types, champs, mutations, requêtes. C'est comme donner le plan complet de votre application à un attaquant. Les scanners vérifient rarement si l'introspection est désactivée.

En audit, nous envoyons une simple requête __schema et obtenons la cartographie complète de l'API. Sur 80% des applications GraphQL que nous auditons, l'introspection est active en production.

Vulnérabilité 2 : Attaques par profondeur (depth attacks)

GraphQL permet des requêtes imbriquées : user { posts { comments { author { posts { comments... } } } } }. Sans limite de profondeur, un attaquant peut construire une requête qui consomme toutes les ressources serveur. C'est un vecteur de déni de service que les scanners n'explorent pas.

Vulnérabilité 3 : Batching attacks

GraphQL accepte plusieurs requêtes dans un seul appel HTTP. Un attaquant peut envoyer 1 000 mutations de login dans une seule requête, contournant ainsi le rate limiting qui opère par requête HTTP. Les scanners testent les endpoints un par un et ne détectent pas cette faille.

Vulnérabilité 4 : IDOR via Relay Global IDs

Le pattern Relay utilise des IDs globaux encodés en base64 (ex: VXNlcjoxMjM= pour User:123). Un attaquant peut décoder ces IDs, incrémenter le numéro, et accéder aux objets d'autres utilisateurs. Les scanners ne comprennent pas la sémantique des IDs Relay.

Vulnérabilité 5 : Contournement d'autorisation sur les résolveurs imbriqués

L'autorisation est souvent vérifiée sur le résolveur racine mais pas sur les résolveurs imbriqués. Exemple : la requête user(id: me) vérifie que vous accédez à votre propre profil. Mais user(id: me) { company { employees { salary } } } peut exposer les salaires de tous les employés si le résolveur employees ne re-vérifie pas les permissions.

C'est la faille GraphQL la plus dangereuse et la plus difficile à détecter automatiquement.

Vulnérabilité 6 : Mutations sensibles sans vérification de rôle

Des mutations comme deleteUser, updateRole, ou exportData existent dans le schéma mais ne vérifient pas le rôle de l'appelant. L'introspection révèle ces mutations, et un simple appel les exécute.

Notre approche d'audit GraphQL

Nous analysons manuellement le schéma exposé, testons les limites de profondeur et de batching, vérifions les autorisations sur chaque résolveur imbriqué, et identifions les mutations sensibles non protégées. C'est un travail d'expert que les scanners ne peuvent pas faire.

À retenir