Comment sécuriser vos API GraphQL contre les injections et fuites de données en 7 étapes

GraphQL a révolutionné la manière dont les applications consomment les API. Sa flexibilité — un endpoint unique, des requêtes sur mesure, un schéma auto-documenté — est exactement ce qui le rend intrinsèquement plus difficile à sécuriser qu’une API REST classique. Sur les 40+ pentests API GraphQL que nous avons menés chez WebGuard Agency entre 2024 et 2026, 92 % présentaient au moins une vulnérabilité critique liée à une mauvaise configuration de sécurité GraphQL.

Ce guide pratique vous accompagne en 7 étapes pour identifier et corriger les vulnérabilités les plus courantes. Chaque étape est tirée de notre expérience terrain et illustrée par des exemples concrets. Pour un panorama plus large de la sécurité API, consultez également notre guide sécurité API REST et GraphQL et notre article sur les vulnérabilités GraphQL.

— Étape 1 : Désactiver l’introspection en production

L’introspection est la fonctionnalité qui permet à un client GraphQL de découvrir automatiquement l’intégralité du schéma : types, champs, relations, mutations, arguments. En développement, c’est un outil priceless pour les développeurs. En production, c’est une feuille de route pour les attaquants.

Sur nos pentests, l’introspection est activée en production dans 67 % des cas. Un attaquant envoie une simple requête { __schema { types { name fields { name type { name } } } } } et obtient la cartographie complète de votre API : tous les types de données, tous les champs disponibles, toutes les mutations, tous les arguments attendus. Avec cette carte, il peut identifier les champs sensibles (email, password, ssn, internalNotes), découvrir des mutations cachées (adminDeleteUser, changeRole), et cartographier les relations entre types pour planifier des requêtes d’exfiltration.

Implémentation pratique : sur Apollo Server, ajoutez introspection: process.env.NODE_ENV !== 'production' dans la configuration. Sur graphql-yoga, utilisez le plugin useDisableIntrospection(). Sur Hasura, définissez la variable d’environnement HASURA_GRAPHQL_ENABLE_INTROSPECTION=false. Vérifiez la désactivation en testant avec un outil comme les outils pentest open-source que nous recommandons, notamment InQL pour Burp Suite ou graphw00f.

— Étape 2 : Limiter la profondeur et la complexité des requêtes

L’une des attaques les plus destructrices contre une API GraphQL est la requête profondément imbriquée. Imaginez un schéma où un User a des posts, chaque Post a des comments, chaque Comment a un author (qui est un User), qui a des posts, etc. Un attaquant peut construire une requête récursive de 50 niveaux de profondeur qui génère des millions de requêtes SQL en cascade, saturant votre base de données en quelques secondes.

Trois mécanismes complémentaires doivent être mis en place :

• Depth limiting : limiter la profondeur maximale des requêtes. Avec la librairie graphql-depth-limit, configurez une profondeur de 6 à 10 niveaux selon votre schéma. Au-delà, la requête est rejetée avec une erreur explicite.
• Query cost analysis : assigner un coût à chaque champ et rejeter les requêtes dépassant un budget total. La librairie graphql-query-complexity permet de définir un maximumComplexity (typiquement entre 500 et 1000 points) et d’attribuer un multiplicateur aux champs qui retournent des listes.
• Pagination obligatoire : ne jamais retourner de liste sans pagination. Imposez les arguments first/last avec un maximum (par exemple 100) et retournez des Connection types avec curseurs plutôt que des listes brutes.

Sur nos pentests, nous testons systématiquement les limites de profondeur en incrémentant progressivement la profondeur de requête jusqu’à obtenir un timeout serveur ou une erreur. 71 % des API GraphQL testées ne possèdent aucune limite de profondeur, ce qui les rend vulnérables à un déni de service applicatif en une seule requête.

— Étape 3 : Implémenter l’authentification et l’autorisation au niveau des résolveurs

C’est l’erreur la plus grave et la plus fréquente que nous rencontrons en pentest : l’autorisation est gérée au niveau du endpoint ou du middleware, mais pas au niveau des résolveurs individuels. En REST, chaque route a ses propres contrôles d’accès. En GraphQL, un utilisateur authentifié peut potentiellement atteindre n’importe quel résolveur via la traversée de relations.

Exemple concret tiré de nos audits : un utilisateur standard envoie la requête { me { organization { users { email role salary } } } }. L’authentification vérifie que l’utilisateur est connecté, mais le résolveur organization.users ne vérifie pas que l’utilisateur a le droit de voir la liste complète des employés, incluant leurs salaires. Résultat : fuite de données massive par traversée de relations.

La règle d’or : chaque résolveur doit vérifier indépendamment les droits de l’utilisateur appelant. Utilisez un système de directives d’autorisation (@auth, @hasRole) appliqué directement dans le schéma, ou un middleware d’autorisation comme graphql-shield qui permet de définir des règles déclaratives par type et par champ. Pour les architectures Hasura, configurez les permissions par rôle au niveau de chaque table et relation.

Nous recommandons également d’implémenter le field-level authorization : certains champs au sein d’un même type peuvent avoir des niveaux d’accès différents. Le champ email d’un User est visible par tous, mais salary n’est visible que par les RH et l’utilisateur concerné. Ce niveau de granularité est indispensable pour les API exposant des données sensibles.

— Étape 4 : Valider et assainir toutes les entrées utilisateur

Le système de types de GraphQL offre une fausse sensation de sécurité. Oui, GraphQL valide que l’argument id est bien un ID! et que name est bien un String. Mais cette validation de type ne protège pas contre les injections : un String peut contenir du SQL, du NoSQL, du LDAP, du XSS ou des caractères de contrôle.

Les points d’injection les plus courants dans les API GraphQL que nous auditons :

• Arguments de filtrage : les résolveurs qui construisent des requêtes SQL dynamiques à partir d’arguments where, filter ou orderBy sont vulnérables aux injections SQL si les valeurs ne sont pas paramétrées.
• Mutations avec entrées libres : les mutations acceptant du texte libre (commentaires, descriptions, messages) sans sanitisation permettent le stockage de payloads XSS qui seront reflétés dans le frontend.
• Scalaires personnalisés : les scalaires custom comme JSON ou Any court-circuitent la validation de type et ouvrent la porte à des injections de structure.
• Directives personnalisées : les directives de schéma non validées qui passent des arguments directement aux couches inférieures (base de données, API tiers) sont des vecteurs d’injection indirects.

Recommandations : utilisez des scalaires custom validés (par exemple EmailAddress, URL, DateTime du package graphql-scalars) plutôt que String générique. Paramétrez toujours les requêtes SQL/NoSQL dans les résolveurs (jamais de concaténation de chaînes). Sanitisez les entrées HTML avec une librairie comme DOMPurify ou sanitize-html avant stockage.

— Étape 5 : Contrôler le batching et les requêtes multiples

GraphQL supporte nativement le query batching : envoyer un tableau de requêtes dans un seul appel HTTP. Cette fonctionnalité, prévue pour optimiser les performances, est détournée par les attaquants pour deux types d’attaques :

Brute force par batching : au lieu d’envoyer 10 000 requêtes d’authentification une par une (facilement détecté par le rate limiting HTTP), l’attaquant envoie un seul POST contenant 10 000 mutations login avec des mots de passe différents. Le rate limiter HTTP voit une seule requête. Sur les 40+ pentests API GraphQL que nous avons réalisés, 58 % étaient vulnérables au brute force par batching.

Exfiltration massive par alias : GraphQL permet d’utiliser des alias pour envoyer la même requête plusieurs fois dans un seul appel. Un attaquant peut exfiltrer les données de milliers d’utilisateurs en une seule requête en utilisant des alias : { u1: user(id: "1") { email } u2: user(id: "2") { email } ... u10000: user(id: "10000") { email } }.

Contre-mesures :

• Limiter le nombre de requêtes par batch (par exemple, maximum 5 requêtes par appel HTTP).
• Limiter le nombre d’alias par requête (la librairie graphql-armor offre cette fonctionnalité).
• Implémenter un rate limiting au niveau GraphQL (par opération, pas seulement par requête HTTP). Des solutions comme graphql-rate-limit ou le rate limiting intégré d’Apollo Server permettent de limiter par type d’opération et par champ.
• Pour les mutations critiques (authentification, changement de mot de passe, paiement), rejeter tout batching.

— Étape 6 : Sécuriser les abonnements WebSocket

Les subscriptions GraphQL via WebSocket introduisent un canal de communication persistant souvent négligé dans les audits de sécurité. Les vulnérabilités spécifiques que nous rencontrons :

• Authentification manquante sur la connexion WebSocket : le handshake WebSocket doit vérifier le token d’authentification. Sans cela, un utilisateur anonyme peut s’abonner à des flux de données sensibles.
• Absence de ré-authentification : une connexion WebSocket ouverte peut rester active après l’expiration du token JWT. Implémentez un mécanisme de vérification périodique (ping/pong avec validation token).
• Fuite de données par subscription : un utilisateur s’abonne à orderUpdated et reçoit les mises à jour de toutes les commandes, pas seulement les siennes. Le filtre d’autorisation doit être appliqué à chaque message publié, pas seulement au moment de l’abonnement.
• Déni de service par subscriptions multiples : sans limite, un attaquant peut ouvrir des milliers d’abonnements simultanés, saturant la mémoire serveur. Limitez le nombre d’abonnements par connexion et par utilisateur.

Pour les implémentations utilisant le protocole graphql-ws, configurez le hook onConnect pour valider le token et le hook onSubscribe pour vérifier les autorisations spécifiques à chaque abonnement. Pour les implémentations utilisant subscriptions-transport-ws (déprécié), migrez vers graphql-ws qui offre un modèle de sécurité plus robuste.

— Étape 7 : Monitorer et auditer en continu

La sécurisation d’une API GraphQL ne s’arrête pas au déploiement des protections. Un monitoring spécifique GraphQL est essentiel pour détecter les tentatives d’attaque et les régressions de sécurité. Voici les métriques et alertes à mettre en place :

• Logger toutes les requêtes rejetées (introspection bloquée, depth limit dépassé, cost limit dépassé, batching limit) avec le contexte utilisateur et l’IP source. Un pic de rejets sur un même endpoint indique une tentative d’attaque active.
• Tracker les erreurs d’autorisation au niveau des résolveurs. Un utilisateur qui déclenche régulièrement des erreurs 403 sur des champs auxquels il n’a pas accès est probablement en train de tester les limites de l’API.
• Surveiller les requêtes lentes : une requête GraphQL dont le temps d’exécution dépasse 5 secondes peut indiquer une tentative de déni de service ou une injection qui provoque un full table scan.
• Auditer les changements de schéma : intégrer un diff de schéma dans votre pipeline CI/CD pour détecter l’ajout accidentel de champs sensibles ou la suppression de directives d’autorisation.
• Pentester régulièrement : un pentest API GraphQL annuel minimum, complété par des scans automatisés mensuels. Notre équipe recommande un cycle trimestriel pour les API exposant des données sensibles. Pour aller plus loin, consultez notre guide comment faire un pentest de votre application.

Pour les outils de monitoring, Apollo Studio (pour Apollo Server) offre un dashboard natif avec les métriques de performance par opération. Pour les implémentations custom, graphql-armor combine en un seul package le depth limiting, le cost analysis, la protection contre le batching et le logging des requêtes bloquées. Intégrez ces logs dans votre SIEM pour corréler avec les autres sources de sécurité. Pour plus de détails sur la mise en place d’un SIEM, consultez notre guide comment mettre en place un SIEM.

— Tableau récapitulatif des 7 étapes

L’effort total pour sécuriser correctement une API GraphQL de complexité moyenne (30 à 80 types, 10 à 40 mutations) se situe entre 5 et 10 jours-développeur. C’est un investissement modéré rapporté au coût d’une fuite de données (en moyenne 4,45 M€ selon IBM, 2025) ou d’une sanction RGPD.

— Questions fréquentes