La flexibilité de GraphQL est précisément ce que les outils conventionnels axés sur REST ne voient pas. 42Crunch applique aux schémas GraphQL le même modèle de sécurité piloté par le contrat qu'il applique déjà à OpenAPI — analyse statique, tests en conditions réelles et application automatisée.
Un point d'entrée unique et flexible, des queries façonnées par le client et des resolvers imbriqués donnent à GraphQL une vraie puissance — et un ensemble distinct de vulnérabilités que les outils conçus pour examiner les routes REST et les verbes HTTP ne vérifient tout simplement pas. L'exposition du schéma, les attaques par épuisement de ressources via des queries profondément imbriquées ou coûteuses, l'accès non autorisé aux données via des champs insuffisamment protégés, les mutations non protégées, et les failles aux frontières des services fédérés se situent tous en dehors de ce qu'un scanner conventionnel recherche.
Laisser l'introspection activée offre à un attaquant l'intégralité de votre graphe de données sous forme de carte, y compris les champs et mutations que personne n'avait l'intention de publier.
Des queries profondément imbriquées ou à coût élevé peuvent transformer une seule requête en déni de service — GraphQL permet à un client de façonner une query comme REST ne l'a jamais permis.
Une faille d'autorisation au niveau d'un champ n'apparaît pas dans une liste de routes — elle se révèle quand le mauvais champ renvoie des données qu'il ne devrait pas.
Les mutations comportent le même risque en écriture qu'un POST ou un PUT REST, mais font rarement l'objet du même examen lors de la revue du schéma.
Un supergraph n'est jamais plus sûr que son subgraph le moins audité — la fédération multiplie la surface d'attaque sans multiplier la revue.
42Crunch évalue directement le SDL GraphQL — le risque d'introspection et d'exposition de données, l'authentification manquante sur les queries et mutations, les chaînes non contraintes et les scalaires personnalisés, l'absence de validation des entrées, la couverture du coût des queries et de la taille des listes, ainsi que la sécurité des subgraphs Apollo Federation. Chaque constat est noté et cartographié, exactement comme un audit de contrat OpenAPI, avant même qu'une seule requête n'atteigne un serveur en production.
Les tests dynamiques pilotés par le contrat vérifient les faiblesses d'authentification et d'autorisation, les abus liés aux opérations imbriquées et à la complexité des queries, les défaillances de sécurité des mutations, les entrées de champ invalides ou malveillantes, ainsi que les problèmes de sécurité liés à la fédération et aux subgraphs — validant que le service en production se comporte comme le schéma le prétend, et pas seulement que le schéma se lit bien.
Une Security Quality Gate GraphQL dédiée compare les résultats d'audit et de scan à un seuil approuvé, et fait échouer le build ou bloque la mise en production lorsqu'un schéma ou une API en production n'atteint pas ce seuil — le même modèle d'application que 42Crunch applique déjà à REST, étendu jusqu'à la couche des queries. Une fois le contrat validé, cette même définition pilote une application précise à l'exécution pendant toute la durée de vie de l'API.
Pas à lui seul. Un WAF opère au niveau HTTP et réseau, sans aucune visibilité sur les spécificités de GraphQL — la structure du schéma, les relations entre resolvers, l'accès au niveau des champs, ou la manière dont un graphe fédéré est composé. Détecter ce qui dysfonctionne réellement dans GraphQL exige une analyse et des tests conscients du schéma, pas seulement une inspection du trafic.
Non. L'Audit SDL statique lit directement la définition du schéma, sans jamais appeler un endpoint en direct. Seul le Scan dynamique se connecte à une API en cours d'exécution — généralement en staging, pas en production — de sorte que l'introspection peut rester désactivée là où c'est le plus important.
Oui — la couverture du coût des queries et de la taille des listes fait partie de l'audit statique, et le scan dynamique teste spécifiquement les abus liés aux opérations imbriquées et à la complexité des queries sur l'API en cours d'exécution, de sorte qu'une query coûteuse est signalée avant de se transformer en déni de service.
Oui, avec une évaluation à la fois des subgraphs et du supergraph. Comme un graphe composé peut masquer les contrôles d'accès propres à un subgraph, 42Crunch reconstitue la propriété des subgraphs et leur contexte de validation, plutôt que de juger le graphe uniquement une fois assemblé.
Oui — les deux sont organisées, auditées, testées et gouvernées au sein de la même plateforme, de sorte qu'un portefeuille mixte REST et GraphQL fonctionne sous une seule politique de sécurité cohérente, au lieu de deux outils déconnectés.
Via des Security Quality Gates GraphQL dédiées. Les résultats d'audit et de scan sont comparés à un seuil approuvé, et un build ou une mise en production peut être automatiquement mis en échec lorsqu'un schéma ou une API en production n'atteint pas ce seuil.
Oui — chaque constat renvoie vers une entrée spécifique à GraphQL dans la Knowledge Database, avec l'emplacement concerné dans le SDL, une explication du risque, un scénario d'attaque réaliste et la correction recommandée.
Oui — les directives de validation utilisées avec Spring GraphQL et graphql-java, notamment @Min, @Max, @Size, @Pattern et @NotEmpty, sont reconnues plutôt que traitées comme une simple décoration opaque du schéma.
Non. C'est un cycle de vie complet : Audit SDL statique, Scan dynamique sur l'API en cours d'exécution, Security Quality Gates en CI/CD, et protection à l'exécution pilotée par le contrat une fois l'API en production.
Pointez 42Crunch vers un schéma GraphQL ou un endpoint en direct, et obtenez en retour un audit noté — sans installation d'agent, sans engagement requis.