Cybersécurité

Sécurité GraphQL : contrer les attaques par surcharge et batching

Apprécié par les équipes de développement pour sa flexibilité, son découplage rigoureux et sa capacité à éliminer le under-fetching et le over-fetching, le langage de requête GraphQL s’est imposé comme un standard incontournable dans les architectures d’API B2B modernes. En permettant aux clients de demander exactement les données dont ils ont besoin au sein d’une unique requête, GraphQL accélère considérablement le développement front-end et réduit la bande passante consommée.

Cependant, cette élégance architecturale s’accompagne d’un changement de paradigme majeur en matière de cybersécurité. En abandonnant la structure REST basée sur la multiplicité des endpoints HTTP (GET, POST, PUT, DELETE sur des URIs distinctes) au profit d’un unique point d’entrée HTTP POST (généralement /graphql), les applications s’exposent à des vecteurs d’attaque inédits.

Loin des généralités sur le Top 10 OWASP, cet article décortique les faiblesses structurelles de la sécurité des API GraphQL : les attaques par récursivité profonde (Query Depth Attack), la surcharge par complexité (Query Complexity Attack) et le batching d’instructions (GraphQL Batching Attack). Nous détaillerons ensuite comment une inspection fine de l’Arbre Syntaxique Abstrait (Abstract Syntax Tree ou AST) réalisée au niveau du WAAP permet d’enrayer ces menaces sans couper les requêtes légitimes de vos utilisateurs.

Les faiblesses structurelles de GraphQL : quand la flexibilité devient une arme

Dans une architecture REST classique, un pare-feu applicatif ou un API Gateway peut facilement appliquer des règles de rate-limiting basées sur des routes explicites (ex: /api/v1/users/login). Dans GraphQL, l’ensemble des opérations (Queries, Mutations, Subscriptions) est véhiculé à travers un payload JSON soumis à un seul endpoint HTTP.

Cette abstraction masque la complexité réelle de la requête au réseau et expose le résolveur (resolver) backend à deux catégories d’attaques par déni de service applicatif (DoS L7) particulièrement dévastatrices.

[ Single Endpoint HTTP POST: /graphql ]
│
▼
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ Analyseur Syntaxique WAAP .OGO │
│ – Extraction & Parsing de l’Arbre Syntaxique Abstrait (AST) │
│ – Calcul de la Profondeur (Depth Limit) │
│ – Calcul du Score de Complexité Globale (Query Cost Analysis) │
│ – Détection du Batching d’Opérations dans l’Array JSON │
└─────────────────────────────────────────────────────────────────────────────────────┘
│ │
(Requête Malveillante / Invalide) (Requête Saine & Autorisée)
│ │
▼ ▼
[ Blocage L7 Immédiat ] [ Exécution par le Résolveur ]

1. Les attaques par récursivité et profondeur de requêtes (Query Depth Attack)

En GraphQL, les types d’objets peuvent entretenir des relations circulaires ou autoréférentielles (par exemple, un auteur a des livres, qui ont un auteur, qui a des livres). Un attaquant peut exploiter cette relation pour construire une requête récursive profondément imbriquée.

GraphQL

# Exemple de requête récursive malveillante à profondeur critique
query MaliciousRecursiveQuery {
author(id: « 102 ») {
books {
author {
books {
author {
books {
author {
name
}
}
}
}
}
}
}
}

Si le résolveur backend ne fixe pas de limite stricte sur la profondeur d’exécution, cette unique requête contraint la base de données sous-jacente à exécuter des dizaines de jointures coûteuses. Envoyée quelques dizaines de fois par seconde, une telle requête entraîne la saturation immédiate des pools de connexions SQL/NoSQL et l’effondrement du service.

2. Le GraphQL Batching Attack : contourner le Rate-Limiting applicatif

Le Batching est une fonctionnalité légitime de GraphQL permettant de regrouper plusieurs requêtes au sein d’un même tableau JSON soumis au serveur HTTP, réduisant ainsi le nombre d’allers-retours réseau.

Cependant, pour un WAF ou un API Gateway conventionnel qui ne comptabilise que les requêtes HTTP brutes, un tableau contenant 1 000 requêtes GraphQL distinctes sera comptabilisé comme une seule et unique transaction HTTP POST.

Les attaquants exploitent cette faille pour exécuter des attaques de force brute complexes (credential stuffing, énumération de jetons MFA ou de données sensibles) en contournant intégralement les règles de rate-limiting configurées au niveau du réseau ou de la passerelle HTTP.

JSON

// Exemple d’attaque par batching : 1 000 requêtes cachées dans 1 seul HTTP POST
[
{« query »: « mutation { login(user: \ »admin\ », pass: \ »123456\ ») { token } } »},
{« query »: « mutation { login(user: \ »admin\ », pass: \ »azerty\ ») { token } } »},
{« query »: « mutation { login(user: \ »admin\ », pass: \ »password\ ») { token } } »}
]

Pourquoi les WAFs traditionnels échouent sur la sécurité des API GraphQL

Les pare-feux d’applications web (WAF) de première génération reposent sur l’analyse de signatures, de chaînes de caractères brutes ou d’expressions régulières (Regex) appliquées à l’URL ou au corps de la requête. Face à GraphQL, cette approche montre ses limites :

Le syndrome du « 200 OK » généralisé : Même lorsqu’une requête GraphQL échoue ou contient des erreurs syntaxiques, le serveur HTTP renvoie quasi systématiquement un code d’état 200 OK accompagné d’un tableau errors dans le corps de la réponse JSON. Les WAFs basés sur le suivi des codes d’erreur HTTP (ex: détection de trop de réponses 401 ou 403) restent totalement aveugles.
L’obfuscation par alias et directives : Un attaquant peut dupliquer une même mutation des centaines de fois au sein d’une seule requête en utilisant des alias GraphQL (alias1: login(…), alias2: login(…)). Une règle Regex classique est incapable de calculer la charge de travail cumulée de ces alias.
L’impact de la surconsommation CPU sur le WAF : Tenter de faire du parsing JSON complet via des Regex complexes au niveau d’un WAF traditionnel augmente drastiquement la latence sur le serveur web d’origine, détruisant l’intérêt premier de l’utilisation de GraphQL.

C’est pourquoi garantir une sécurité efficace des API et applications web exige un moteur de filtrage capable de comprendre la grammaire native de GraphQL.

[TESTEZ LA RÉSISTANC E DE VOS API]

Vos résolveurs GraphQL sont-ils protégés contre les injections et la surcharge ?

Un simple audit de vos schémas et de vos endpoints permet d’identifier les risques de DoS L7 et de fuite de données avant qu’ils ne soient exploités.

Lancer un audit automatisé des API via l’offre ITrust ou Découvrez la protection GraphQL native par la solution .OGO.

L’approche WAAP de nouvelle génération : L’inspection AST à l’Edge

Pour sécuriser un endpoint GraphQL sans pénaliser les performances des applications B2B, le filtrage doit s’effectuer en amont du résolveur, directement sur la couche d’inspection du WAAP de nouvelle génération.

Plutôt que d’analyser le payload comme une simple chaîne de texte, la technologie .OGO intègre un parseur haute performance qui transforme la requête entrante en son Arbre Syntaxique Abstrait (AST – Abstract Syntax Tree) en une fraction de milliseconde.

Requête GraphQL Brute (JSON / HTTP POST)
│
▼
┌──────────────────────────────────────────┐
│ Parseur AST Haute Performance (.OGO) │
└──────────────────────────────────────────┘
│
┌────────────────────────┴────────────────────────┐
▼ ▼
┌─────────────────────────┐ ┌─────────────────────────┐
│ Calcul de Profondeur │ │ Calcul du Score │
│ (Max Depth Checking) │ │ de Complexité (Cost) │
└─────────────────────────┘ └─────────────────────────┘
│ │
└────────────────────────┬────────────────────────┘
▼
[ Évaluation du Seuil de Sécurité ]

1. Analyse de la profondeur maximale (Depth Limiting)

Lors de l’étape de construction de l’AST, le WAAP parcourt les nœuds de la requête pour en dériver instantanément la profondeur maximale. Si l’imbrication dépasse le seuil maximal configuré pour l’application (par exemple, 5 ou 7 niveaux d’objets), la requête est immédiatement rejetée à l’Edge avec un code de blocage clair, avant même d’avoir sollicité le moteur Node.js, Python ou Go de votre backend.

2. Calcul du score de complexité globale (Query Cost Analysis)

Chaque champ ou relation dans un schéma GraphQL a un coût fixe ou multiplicatif sur l’infrastructure.

Le moteur d’IA comportementale et d’analyse d’.OGO attribue une pondération aux différents nœuds de l’AST. Si une requête combine de multiples alias, des fragments complexes et des requêtes imbriquées dont le score de coût global excède la limite autorisée par session, le WAAP neutralise l’appel.

3. De-batching et décomptage réel des requêtes L7

Au niveau de la couche réseau, le WAAP déplie virtuellement les tableaux de requêtes batchées.

Chaque opération incluse dans le tableau JSON est évaluée individuellement vis-à-vis des règles de rate-limiting et des mécanismes de détection de vulnérabilités applicatives type SQL et XSS. Si un attaquant tente de faire passer 500 tentatives de connexion dans un seul flux POST, le WAAP comptabilise 500 événements distincts et applique instantanément le bannissement de la source.

Tableau comparatif : Stratégies de sécurisation GraphQL

Mécanisme de sécurité	Validation par le Code Backend (Resolvers)	API Gateway / WAF Historique	WAAP de Nouvelle Génération (.OGO)
Analyse AST en Temps Réel	Oui (Mais consomme CPU / RAM Backend)	Non (Traite le JSON comme du texte)	Oui (Exécuté à l’Edge en < 1ms)
Limitation de Profondeur (Depth)	Oui (Bibliothèques manuelles)	Non	Automatique & Déclarative
Protection GraphQL Batching	Complexe à coder manuellement	Inefficace	Totale (Inspection individuelle des sous-requêtes)
Introspection Blocking en Prod	Souvent oubliée dans le code	Non gérée	Activée en 1 clic au périmètre
Impact sur la Latence Applicative	Élevé sur requêtes complexes	Faible mais inefficace	Nul (Soulage la charge du backend)

4 étapes pour durcir immédiatement la sécurité de vos API GraphQL

Étape 1 : Désactiver l’Introspection en environnement de production

L’introspection permet aux développeurs de requêter le schéma complet de l’API (__schema). En production, les attaquants utilisent l’introspection pour cartographier instantanément l’ensemble de vos types, mutations et failles potentielles. Désactivez-la au niveau de votre serveur GraphQL ou bloquez la métadonnée __schema directement sur votre WAAP.

Étape 2 : Imposer une limite de profondeur stricte (Max Depth)

Analysez les requêtes légitimes générées par vos clients web et mobiles. Déterminez la profondeur maximale requise (rarement supérieure à 5 ou 6 niveaux) et appliquez un rejet strict au-delà de cette limite sur votre passerelle de sécurité.

Étape 3 : Neutraliser le Batching sur les mutations critiques

Incitez vos équipes de développement à séparer les requêtes de lecture (Queries) des opérations de modification (Mutations). Interdisez le batching d’opérations sur les endpoints réalisant des tâches sensibles (authentification, paiements, modifications de profil).

Étape 4 : Déployer un filtrage au niveau de la couche WAAP

Confiez l’analyse syntaxique AST et la régulation de débit à une solution spécialisée. Cela garantit que vos serveurs d’application ne consacrent leur puissance de calcul qu’au traitement des requêtes métier légitimes.

Protégez l’élégance de GraphQL grâce à une sécurité adaptée

GraphQL offre une flexibilité exceptionnelle aux développeurs B2B, mais cette souplesse ne doit pas se faire au détriment de la résilience de vos infrastructures. Répondre aux défis du batching et de la surcharge récursive par des correctifs manuels dans le code applicatif s’avère coûteux, complexe à maintenir et source de dette technique.

En déployant une protection WAAP souveraine et intelligente comme .OGO, vous bénéficiez d’une inspection AST native à l’Edge qui préserve vos résolveurs, bloque les abus de complexité et sécurise l’ensemble de vos API GraphQL en toute transparence.

Passez à l’action pour la sécurité de vos API