Dans le trafic REST, l'endpoint, la méthode et le chemin décrivent généralement ce que fait une requête. Dans GraphQL, ces informations résident principalement dans le corps. Le même endpoint `/graphql` peut transporter des lectures, des écritures, des requêtes imbriquées, de l'introspection, des fragments et des opérations pilotées par des variables. Une couche de sécurité qui ne vérifie que l'URL et la méthode ne peut pas voir ce que GraphQL fait réellement.
Lorsque l'introspection GraphQL reste ouverte en production, le schéma de l'application peut fuiter. Un attaquant qui apprend quels types, champs et relations existent peut élaborer des requêtes beaucoup plus ciblées. Ce n'est peut-être pas une exfiltration directe de données, mais c'est une divulgation d'informations sérieuse qui cartographie la surface d'attaque.
Les requêtes imbriquées et les fragments créent un risque différent. Des requêtes excessivement imbriquées peuvent imposer une lourde charge de traitement au backend avec une seule requête HTTP. Le rate limiting standard compte les requêtes — il ne voit pas le coût d'une seule requête. Dans GraphQL, le risque de DoS vient généralement de la structure de la requête, pas du volume de requêtes.
Le query batching produit un fossé similaire. Lorsque plusieurs requêtes sont envoyées dans un seul corps, le trafic ressemble à une seule requête HTTP de l'extérieur, mais plusieurs opérations peuvent s'exécuter à l'intérieur. Cela compromet les contrôles de sécurité classiques basés sur le rate limit et les endpoints.
TR7 GraphQL Deep Inspection examine le trafic GraphQL avec des règles WAAP basées sur les patterns : les comportements d'introspection, de DoS par profondeur imbriquée et de query batching sont détectés sur les portées query, raw, json et form et liés aux politiques de production.
TR7 aborde la sécurité GraphQL non pas en revendiquant une conscience du schéma, mais en intégrant les patterns d'abus GraphQL les plus courants en production dans le moteur de signatures WAAP.
TR7 capture les indicateurs d'introspection tels que `__schema`, `__type`, `IntrospectionQuery` et `fragment FullType` à l'aide de règles basées sur la regex. Ces règles peuvent s'exécuter en mode blocage en production et en mode surveillance ou à un score plus bas en qualification.
Les requêtes GraphQL excessivement imbriquées peuvent générer une lourde charge de traitement avec une seule requête. La famille de règles TR7 50101 détecte les chaînes `{ ... { ... } }` profondes au niveau du pattern et les inclut dans la décision WAAP avec un score élevé.
Envoyer plusieurs requêtes dans un seul corps peut compromettre la logique classique de rate limit. La règle TR7 50102 détecte les patterns de batch query et permet de lier ce comportement à une décision de journalisation, de scoring ou de blocage.
Une requête GraphQL peut être transportée non seulement dans le corps brut mais aussi dans des champs JSON, de formulaire ou de chaîne de requête. Les règles TR7 s'exécutent sur les portées query, raw, json et form, mettant les différentes implémentations client sous la même politique WAAP.
GraphQL Deep Inspection gère les risques spécifiques à GraphQL avec des règles WAAP basées sur les signatures, la sélection de portées et des contrôles de renforcement des endpoints.
La règle 50100 cible les patterns couramment utilisés dans l'introspection GraphQL : `__schema`, `__type`, `IntrospectionQuery` et `fragment FullType`. Le niveau de risque par défaut est positionné comme un signal de force moyenne et peut être évalué à un score de 4. Sur les endpoints où l'introspection doit être fermée en production, cette règle peut s'exécuter en mode blocage ou surveillance. Les tentatives de découverte de schéma deviennent visibles dans le flux d'événements WAAP.
La règle 50101 détecte les requêtes GraphQL excessivement imbriquées au niveau du pattern. Des chaînes `{` profondes et des structures fortement imbriquées peuvent faire en sorte qu'une seule requête impose un coût de traitement élevé au backend. Cette règle peut être évaluée à un score de 6 comme signal d'attaque plus fort. L'objectif n'est pas d'effectuer un calcul de complexité schema-aware — c'est de capturer tôt les patterns de requêtes imbriquées dangereux.
La règle 50102 détecte les patterns de batch où plusieurs requêtes sont envoyées dans un seul corps. Étant donné que le query batching peut être légitime pour certains clients, l'état et les valeurs de score de la règle doivent être ajustés au comportement de l'application. Démarrer en mode surveillance et clarifier avec l'observation du trafic réel est la bonne approche. Une fois l'abus confirmé, la règle peut être déplacée vers une politique de blocage.
En plus des règles enrichies TR7, waf_db contient des variantes GraphQL telles que les familles 50100, 50101 et 21360+. Ces variantes couvrent des orthographes alternatives telles que `__schema {`, `__type`, `__typename` et les patterns de mutation imbriqués. Cela construit une surface de signature plus large pour les comportements d'introspection et de requêtes imbriquées sans dépendre d'une seule regex. Les opérateurs peuvent remplacer l'état et le score de ces règles par service.
Les requêtes GraphQL n'arrivent pas toujours dans le même format. Certains clients envoient les champs `query`, `variables` et `operationName` dans un corps JSON ; d'autres peuvent utiliser le corps brut ou les champs de formulaire. Les règles TR7 s'exécutent sur les portées query, raw, json et form, mettant ces différents formats de transport sous la couverture d'inspection. Cela réduit l'erreur de ne faire confiance qu'à un seul format de corps sur les endpoints GraphQL.
Les contrôles GraphQL peuvent être appliqués aux cibles api_endpoint et web_application. Le même modèle de règles WAAP peut être géré avec des valeurs d'état, de score ou de portée différentes selon le type de service. Par exemple, l'introspection peut rester en mode surveillance sur un endpoint de test interne tout en étant bloquée sur un endpoint de production public. Cette flexibilité permet à un seul ensemble de règles d'être adapté à différentes politiques d'environnement.
Des contrôles peuvent être définis pour l'endpoint `/graphql` tels que n'autoriser que la méthode POST, restreindre les clés JSON attendues à `query`, `variables` et `operationName`, ou appliquer une limite de taille du corps. Ces contrôles ne remplacent pas les signatures GraphQL — ils constituent une couche de sécurité positive qui les complète. Les méthodes inattendues ou les champs JSON inattendus peuvent être rejetés à un stade précoce, rendant le comportement de l'endpoint plus prévisible.
Si le trafic GraphQL inclut des patterns de mutation spécifiques à l'application, des noms de champs ou des noms d'opérations risqués, ils peuvent être ajoutés comme règles WAAP personnalisées. Par exemple, un mot-clé `mutation` spécifique ou un nom d'opération sensible apparaissant dans le corps peut se voir attribuer un score plus élevé. Ces règles personnalisées participent au système de scoring WAAP principal et sont visibles dans le flux de journaux et SIEM. Même sans inspection de champs schema-aware, les risques spécifiques à l'application peuvent être capturés avec des règles basées sur les patterns.
GraphQL Deep Inspection est basé sur les signatures dans ses capacités réelles actuelles — le parsing des opérations, le calcul de complexité et les revendications de WAAP de champs schema-aware sont hors périmètre de cette page.
Les contrôles GraphQL fonctionnent avec une approche de détection de patterns basée sur la regex et les portées. La différenciation des types d'opérations, un vrai compteur de profondeur ou le calcul d'un score de complexité de requête ne font pas partie de ce modèle. Cette distinction est particulièrement importante pour un positionnement précis.
Les règles 50100, 50101, 50102 et les variantes waf_db peuvent être définies sur enabled, monitor ou disabled selon les besoins du service. Les valeurs de score peuvent également être ajustées à la tolérance aux faux positifs de l'application. Le bon modèle de déploiement pour les endpoints GraphQL de production est de démarrer en mode surveillance et de passer au blocage après observation du trafic réel.
Une allow-list de méthodes, une allow-list de clés JSON et une limite de taille du corps peuvent être appliquées sur les endpoints GraphQL. Ces contrôles garantissent que la forme de la requête est conforme au contrat attendu en complément de la détection par signatures. Sur les API publiques en particulier, n'accepter que le format attendu sur l'endpoint `/graphql` réduit la surface d'attaque.
Le rate limiting par opération n'est pas appliqué au niveau du parseur GraphQL. Il n'y a aucune revendication de parser sémantiquement le nombre d'opérations dans un seul corps et d'appliquer une limite séparée à chacune. Le pattern de query batching peut être capturé comme signature et utilisé en parallèle avec les politiques générales de rate limit.
Il n'y a pas de prise en charge dédiée des requêtes persistées dans cette capacité. Les patterns GraphQL visibles dans la requête sont inspectés avec les signatures WAAP. La résolution d'une requête depuis son hash et sa vérification par rapport au schéma ou aux données d'opération enregistrées n'est pas revendiquée sur cette page.
L'inspection native au niveau d'un champ de schéma GraphQL spécifique — par exemple `User.email` — n'est pas effectuée. Les règles fonctionnent avec une approche de correspondance de patterns sur le corps. S'il y a des exigences spécifiques aux champs, elles doivent être traitées de manière limitée et prudente avec une règle regex personnalisée.
Une équipe sécurité peut autoriser l'introspection en qualification tout en exécutant la règle 50100 en mode blocage sur l'endpoint de production. Les tentatives de découverte de schéma sont journalisées, scorées et bloquées par politique.
Des fragments ou structures de requêtes excessivement imbriqués peuvent imposer un coût de traitement élevé au backend. La règle 50101 capture ces patterns avec un score de 6, fournissant un signal fort pour la décision de blocage WAAP.
Lorsque de nombreuses requêtes sont tentées dans une seule requête vers un endpoint client mobile, la règle 50102 détecte le pattern de batch. L'équipe opérationnelle peut observer le comportement en mode surveillance en premier et passer en mode activé une fois l'abus confirmé.
Une équipe API peut n'autoriser que la méthode POST et les champs JSON `query`, `variables` et `operationName` sur l'endpoint `/graphql`. Les méthodes ou champs inattendus sont rejetés avant d'atteindre l'application, réduisant le comportement de l'endpoint.
Rendez les risques d'introspection, de DoS imbriqué et de query batching visibles et gérables en production. Parcourons ensemble une configuration en direct sur vos propres services.