GraphQL : 5 attaques spécifiques que les scanners ratent

Pourquoi les scanners échouent sur GraphQL

Les scanners de vulnérabilités sont conçus pour les API REST : ils testent chaque endpoint, chaque méthode HTTP, chaque paramètre. GraphQL n'a qu'un seul endpoint (/graphql), une seule méthode (POST), et un langage de requête flexible. Les outils automatisés passent à côté des vulnérabilités spécifiques à ce paradigme.

Attaque 1 : introspection activée en production

GraphQL propose une fonctionnalité d'introspection qui retourne le schéma complet : tous les types, toutes les queries, toutes les mutations, tous les champs. En production, c'est l'équivalent de publier votre documentation API complète avec les endpoints d'administration.

Test : envoyez {"query": "{__schema{types{name fields{name}}}}"}. Si ça retourne le schéma, l'introspection est activée.

Correction : désactivez l'introspection en production. Sur Apollo Server : introspection: false. Mais attention, certains outils de monitoring internes peuvent en dépendre.

Attaque 2 : query batching pour contourner le rate limiting

GraphQL permet d'envoyer plusieurs opérations dans une seule requête HTTP. Si le rate limiting compte les requêtes HTTP et non les opérations GraphQL, l'attaquant envoie des centaines de mutations de login dans une seule requête pour du brute force.

Exemple : [{"query": "mutation { login(email:'admin', password:'pass1') { token } }"}, {"query": "mutation { login(email:'admin', password:'pass2') { token } }"}]

Correction : comptez les opérations GraphQL individuellement, pas les requêtes HTTP.

Attaque 3 : deep queries et Denial of Service

Les relations circulaires permettent de créer des requêtes exponentiellement profondes. { user { posts { author { posts { author { posts { ... } } } } } } } peut consommer des gigaoctets de mémoire côté serveur.

Correction : implémentez une limite de profondeur de requête (query depth limiting) et une analyse de coût (query cost analysis). Des bibliothèques comme graphql-depth-limit et graphql-cost-analysis existent pour Node.js.

Attaque 4 : alias pour l'extraction massive

Les aliases GraphQL permettent d'appeler le même champ plusieurs fois avec des arguments différents dans une seule requête : { u1: user(id:1) { email } u2: user(id:2) { email } u3: user(id:3) { email } }. L'attaquant extrait des milliers de profils en quelques requêtes.

Correction : limitez le nombre d'aliases par requête ou implémentez une analyse de coût qui compte les aliases.

Attaque 5 : injection dans les directives et fragments

Les directives personnalisées et les fragments peuvent être des vecteurs d'injection si leur traitement côté serveur n'est pas sécurisé. Les fragments permettent aussi de contourner les contrôles d'accès si la résolution des types ne vérifie pas les autorisations à chaque niveau.

Exemple : un fragment sur un type union peut révéler des champs d'un type auquel l'utilisateur n'a pas accès si la vérification est faite uniquement au niveau de la query racine.

Ce que nous recommandons

CleanIssue teste systématiquement ces cinq vecteurs lors de chaque audit d'API GraphQL. Parlez-nous de votre revue externe.