GraphQL permet à une application de demander précisément les champs dont elle a besoin, à travers un schéma qui décrit les données disponibles. Cette souplesse simplifie certaines interactions avec les API, mais elle exige une attention particulière à la sécurité, notamment lorsque les requêtes traversent plusieurs relations.
Pour une équipe qui prépare une mise en production, les enjeux sont concrets : limiter les données accessibles, contrôler chaque opération et prévenir les abus de ressources. Comprendre les principaux risques d’exploitation aide à choisir des mesures de protection adaptées, sans renoncer aux avantages de GraphQL.
A retenir :
- Schéma GraphQL documenté et accès sensibles soumis à autorisation
- Requêtes limitées en profondeur, complexité et fréquence
- Erreurs serveur filtrées avant leur exposition aux clients
- Authentification complétée par une validation propre à chaque objet
Exploitation GraphQL : comprendre les risques de sécurité
Une fois les besoins de protection identifiés, il faut comprendre pourquoi le modèle GraphQL modifie les contrôles habituels des API. Là où une API REST répartit souvent ses opérations sur plusieurs routes, GraphQL concentre généralement les demandes sur un point d’entrée et laisse le client préciser les champs souhaités.
Schéma et introspection : les informations à protéger
Ce fonctionnement repose sur un schéma typé qui décrit les objets, les champs et les opérations disponibles. Selon GraphQL.org, l’introspection sert à interroger cette structure ; utile au développement, elle peut aussi faciliter la cartographie d’une API lorsqu’elle reste accessible sans contrôle en production.
L’introspection n’est pas une vulnérabilité à elle seule : le risque dépend des données révélées et des protections appliquées aux opérations. Une équipe peut la restreindre en production, réduire les suggestions de champs dans les erreurs et documenter les opérations nécessaires aux clients.
Mesures de visibilité du schéma :
- Réserver l’introspection aux environnements et rôles autorisés
- Retirer des erreurs les détails internes et les chemins serveur
- Examiner les champs sensibles et leurs relations
Requêtes complexes : limiter le coût côté serveur
Le schéma peut relier des objets entre eux, et une requête profonde risque donc de déclencher de nombreux résolveurs. Selon OWASP, les API doivent notamment maîtriser la consommation de ressources ; pour GraphQL, cela passe par des plafonds de profondeur, de complexité et de fréquence.
Risque
Effet possible
Contrôle défensif
Imbrication excessive
Multiplication des résolutions
Limite de profondeur
Alias nombreux
Répétition d’opérations dans une requête
Budget de complexité
Requêtes groupées
Plusieurs opérations par envoi
Limites de traitement et de débit
Réponses volumineuses
Charge accrue sur le serveur
Pagination et plafonds de résultats
Au lieu de fixer un seuil au hasard, l’équipe peut mesurer le coût des requêtes légitimes et ajuster les limites selon ses usages. Les journaux de performance aident à repérer les opérations coûteuses avant qu’elles ne dégradent le service pour les utilisateurs.
Vulnérabilités GraphQL : sécuriser les données et les opérations
La maîtrise de la charge ne suffit pas : les droits doivent aussi suivre chaque chemin d’accès au sein du graphe. Cette vérification devient particulièrement importante quand une requête ou une mutation accepte l’identifiant d’un objet appartenant à un autre compte.
Authentification et autorisation au niveau des objets
L’authentification établit l’identité du demandeur, tandis que l’autorisation détermine les données qu’il peut lire ou modifier. Confondre les deux laisse parfois un utilisateur connecté accéder à une commande, un profil ou un dossier qui ne lui appartient pas.
Pour chaque résolveur, vérifiez que les droits correspondent à l’objet demandé et à l’action envisagée. Une mutation de modification doit contrôler le propriétaire ou un rôle explicitement autorisé, au lieu de se fier uniquement à la présence d’une session valide.
Vérifications des accès métier :
- Associer chaque objet demandé à une règle d’accès
- Tester les rôles avec des comptes distincts
- Refuser par défaut les opérations non autorisées
Validation des arguments et réponses d’erreur
Le typage GraphQL aide à structurer les entrées, mais ne remplace pas leur validation métier. Un argument de recherche ou une URL reçue par mutation doit être contrôlé avant utilisation, notamment si un résolveur interagit avec une base de données ou un service interne.
Selon OWASP, la validation des entrées et la limitation des erreurs informatives font partie des pratiques de défense des API. En production, une réponse générique évite de divulguer des détails techniques, tandis que les journaux internes conservent les éléments utiles au diagnostic.
Contrôles des entrées :
- Valider format, longueur et valeurs autorisées
- Employer des requêtes paramétrées côté base de données
- Limiter les destinations réseau fournies par les clients
Ces contrôles prennent toute leur valeur lorsqu’ils sont intégrés aux tests et à la configuration de production. Selon la documentation d’Apollo Server, les équipes peuvent aussi s’appuyer sur des requêtes persistées ; celles-ci permettent de restreindre les opérations acceptées lorsqu’elles sont configurées pour cet usage.
Protection d’une API GraphQL : méthodes et outils d’audit
Après les contrôles par opération, l’audit vérifie que les protections tiennent ensemble dans le déploiement réel. Une équipe peut commencer par examiner les paramètres du serveur, puis tester les limites avec des requêtes représentatives et des comptes aux permissions différentes.
Audit GraphQL autorisé : une méthode reproductible
Un audit encadré inventorie les opérations accessibles, vérifie l’exposition du schéma et compare les droits entre utilisateurs. Il examine également la pagination, les erreurs et le comportement du service face aux requêtes coûteuses, sans lancer de tests hors périmètre.
Étape
Question de contrôle
Résultat attendu
Configuration
Les fonctions de développement sont-elles restreintes ?
Accès limité en production
Autorisation
Chaque objet vérifie-t-il les droits du demandeur ?
Accès conforme au rôle
Charge
Les requêtes coûteuses rencontrent-elles des limites ?
Rejet ou traitement maîtrisé
Erreurs
Les réponses révèlent-elles des détails internes ?
Messages externes filtrés
Des outils d’inspection ou d’analyse peuvent assister ces vérifications, à condition de les utiliser sur une API que l’organisation est autorisée à tester. Leurs résultats demandent une validation humaine : un signal automatisé indique une piste, pas nécessairement une vulnérabilité exploitable.
Étapes d’un audit défensif :
- Définir le périmètre et les comptes de test
- Examiner schéma, erreurs et paramètres de production
- Vérifier les droits sur chaque type d’objet
- Consigner les corrections et refaire les tests
Mesures de production : réduire l’exposition durablement
Les mesures efficaces se complètent : limites de profondeur et de complexité, contrôle de débit, pagination et suivi des erreurs réduisent des risques différents. Une règle isolée peut laisser un autre chemin ouvert, par exemple si un accès est protégé mais qu’une opération équivalente reste disponible ailleurs.
Pour une petite équipe, l’ordre pratique consiste à sécuriser d’abord les données sensibles et les mutations, puis à ajuster les limites avec des mesures d’usage. Cette discipline transforme GraphQL en interface maîtrisable, plutôt qu’en point d’accès difficile à surveiller.
La documentation de l’API et la revue régulière des changements complètent ces protections techniques. Lorsqu’un nouveau champ ou une nouvelle relation apparaît, il faut réexaminer les permissions, la charge induite et les données susceptibles d’être exposées.
Source : GraphQL Foundation, « GraphQL », GraphQL.org ; OWASP Foundation, « GraphQL Cheat Sheet », OWASP ; Apollo, documentation d’Apollo Server sur les requêtes persistées.
