Les risques de sécurité des API GraphQL que tout développeur doit connaître

Qu’est-ce que la sécurité des API GraphQL ?

La sécurité des API GraphQL regroupe des pratiques et des contrôles spécialisés qui protègent les endpoints GraphQL. Elle vise à réduire les risques et les vulnérabilités liés à la nature flexible et à l’architecture particulière de GraphQL. On pense au sur-requêtage, à la complexité excessive des requêtes, aux problèmes d’injection, à l’usage abusif de l’introspection de schéma et à l’exploitation de la profondeur des requêtes.

Renforcez votre sécurité cloud

Découvrez des pratiques avancées pour réduire les risques, prioriser les actions et protéger vos environnements cloud à grande échelle.

Votre adresse e-mail professionnelle ici

Télécharger

Ce qui distingue la sécurité de GraphQL

Contrairement aux API REST, généralement orientées ressources, GraphQL est piloté par le schéma et repose sur les composants suivants :

• Schemas : plans qui décrivent la structure des données et les opérations que les clients peuvent effectuer ;

• Resolvers : fonctions chargées de lire, créer, mettre à jour ou supprimer les données de certains champs du schéma ;

• Queries, mutations et subscriptions : opérations principales qui récupèrent des données, les modifient ou reçoivent des mises à jour poussées.

Les capacités de GraphQL passent souvent par un seul endpoint HTTP (par exemple https://api.yourdomain.com/api/graphql). Cet endpoint accepte généralement la méthode POST, et parfois GET pour les requêtes ou les persisted queries, avec des requêtes contrôlées par le client. Le contenu du corps de la requête détermine alors comment les données sont consultées ou modifiées selon le schéma.

Cette grande flexibilité constitue un atout majeur, mais elle crée aussi des défis de sécurité. Ce modèle accepte un nombre illimité de requêtes valides en entrée, il devient donc exploitable dès qu’il n’est pas contrôlé correctement.

En résumé, GraphQL réclame des défenses techniques qui vont au-delà des bonnes pratiques de sécurité des API REST. Avant d’examiner les protections, regardons de plus près les vecteurs d’attaque.

Bonnes pratiques avancées de sécurité des API

Téléchargez le guide des bonnes pratiques de sécurité des API de Wiz et renforcez votre infrastructure d’API grâce à des techniques éprouvées, pensées pour une gestion des API sécurisée et performante.

Principales vulnérabilités et vecteurs d’attaque de GraphQL

OWASP, GraphQL.org et Apollo mettent en avant plusieurs risques de sécurité qui touchent les API GraphQL.

Problèmes d’autorisation

Avec GraphQL, les clients composent librement les requêtes de leur choix. Cette structure de requête très souple rend le role-based access control (RBAC) plus difficile à mettre en place que dans les API REST classiques.

Sans autorisation stricte au niveau des champs, des informations sensibles peuvent être exposées, même quand des règles d’accès de plus haut niveau s’appliquent. Un utilisateur autorisé à interroger son profil pourrait par exemple accéder à des champs masqués comme role, ou les manipuler, si ceux-ci ne sont pas restreints.

Cette liberté dans la récupération des données ouvre aussi la voie aux attaques de type insecure direct object reference (IDOR). Un schéma GraphQL courant consiste à utiliser un champ racine qui accepte un identifiant, comme un id, pour récupérer un objet précis. Par exemple :

query GetCompanyDetails($companyId: ID!) {
  company(id: $companyId) {
    name
    email
  }
}

Que se passe-t-il si le resolver du champ company n’applique pas de vérifications d’autorisation correctes ? Un attaquant pourrait incrémenter le $companyId de sa valeur autorisée (par exemple 100) vers une autre valeur (par exemple 101) et accéder à des données qui ne lui sont pas destinées.

Menaces de déni de service

Autre risque majeur à garder en tête : la flexibilité de GraphQL permet de le détourner pour des tentatives de déni de service (DoS) :

• les attaquants peuvent produire des requêtes volontairement trop imbriquées ou avec des dépendances circulaires qui déclenchent un excès d’appels aux resolvers. Résultat : un serveur saturé qui épuise vite ses ressources ;

• le query batching réduit l’efficacité des limiteurs de débit naïfs, car un utilisateur malveillant combine plusieurs opérations coûteuses dans une seule requête et contourne ainsi ces limiteurs. Comme les backends GraphQL n’exposent souvent qu’un seul endpoint, une limitation de débit efficace reste difficile à concevoir ;

• les attaquants exploitent aussi l’amplification par alias, en masquant des opérations coûteuses répétées sous différents alias de champ ;

• une autre tactique consiste à envoyer des requêtes dites « bombes de complexité ». L’attaquant étudie votre schéma GraphQL public pour composer des requêtes qui semblent simples, mais qui exigent de lourds calculs côté backend.

Sécurité des API non gérées : ce que les équipes cloud doivent savoir. Les API non gérées sont des interfaces non documentées qui fonctionnent en dehors des cadres standard de sécurité et de gouvernance. En savoir plus

Introspection du schéma et surexposition des données

Grâce à la fonction d’introspection, les utilisateurs écrivent des requêtes spéciales pour découvrir le schéma de l’API GraphQL, par exemple les types, les champs et les opérations disponibles. C’est utile pour les développeurs, mais, vous l’aurez deviné, cela introduit aussi des vulnérabilités.

Des acteurs malveillants exploitent facilement les requêtes d’introspection pour mener des attaques de découverte de schéma. Leur but : repérer des types de données privés, des champs non documentés, des fonctions d’administration et bien plus. Ils rédigent ensuite des requêtes très ciblées qui provoquent des fuites de données, des attaques par déni de service et d’autres exploits.

Retenez ceci : l’exposition des données personnelles des utilisateurs peut représenter un problème de conformité majeur. Les infractions à des réglementations sur la vie privée comme le RGPD et le CCPA entraînent des amendes lourdes.

Divulgation d’informations via la gestion des erreurs

Comme les API REST, les endpoints GraphQL peuvent divulguer à votre insu des informations sensibles à cause d’une mauvaise gestion des erreurs. Quand une requête invalide est envoyée, un serveur mal configuré renvoie parfois des messages d’erreur verbeux qui révèlent des détails sur la stack technique ou sur certaines parties du schéma.

Une erreur comme "Cannot query field 'userRole' on type 'Query'. Did you mean 'role'?" révèle l’existence du nom de champ role. De même, une erreur telle que "Cannot query field 'salary' on type 'User'" expose l’existence d’un champ salary, même si son accès est restreint.

Les threat actors qui repèrent ces failles de gestion des erreurs commencent à envoyer des requêtes automatisées et aléatoires. Ils analysent les réponses d’erreur pour en apprendre le plus possible sur votre schéma GraphQL, puis retournent ces informations contre vous.

La gestion de la posture de sécurité des API expliquée. L’API security posture management, ou API-SPM, est une discipline de sécurité qui vise à maintenir et à améliorer de façon proactive la santé de sécurité des API d’entreprise. En savoir plus

Attaques par injection sur GraphQL

En raison de sa nature ouverte aux entrées, GraphQL est particulièrement vulnérable aux attaques par injection classiques. Les attaques par injection figurent d’ailleurs parmi les compromissions GraphQL les mieux documentées.

La capacité des utilisateurs à contrôler les entrées des requêtes ouvre la porte à de nombreux problèmes :

• l’injection SQL, qui survient si un argument est concaténé directement dans une chaîne de requête envoyée à une database. Pour l’éviter, privilégiez toujours les requêtes paramétrées ou les instructions préparées plutôt que la concaténation de chaînes ;

• l’injection de commandes, qui apparaît si un resolver utilise une chaîne fournie par l’utilisateur pour exécuter une commande système sur le serveur. Réduisez ce risque en évitant les appels shell directs et en validant les entrées avec des listes blanches strictes ;

• la prompt injection, où une entrée fournie par l’utilisateur s’insère dans des prompts d’IA générés dynamiquement pour détourner leur comportement prévu. Limitez ce problème en séparant l’entrée utilisateur des instructions système, en assainissant l’entrée et en appliquant des guardrails qui restreignent ce que l’IA peut faire.

CSRF sur les opérations de mutation

Le cross-site request forgery (CSRF) survient quand un site malveillant amène un navigateur à exécuter des actions non voulues sur un site de confiance où l’utilisateur est déjà connecté. Cette vulnérabilité concerne souvent les opérations de mutation, mais les opérations de requête qui déclenchent des effets de bord dans des systèmes mal conçus peuvent aussi être détournées.

Les backends GraphQL sont particulièrement exposés au CSRF en raison de leur endpoint API POST unique et prévisible. Un acteur malveillant peut intégrer un script JavaScript caché dans un site piégé qui envoie une mutation forgée vers l’endpoint de l’API GraphQL. Quand un utilisateur authentifié visite la page de l’attaquant, son navigateur inclut automatiquement les cookies de session et envoie une requête au backend GraphQL comme si elle venait de l’utilisateur légitime.

Failles générales de sécurité des API

Comme les backends GraphQL sont des backends d’API, ils sont soumis à tous les risques de sécurité des API courants. On pense au contournement d’autorisation, à la broken authentication, à la broken object-level authorization, à l’accès illimité à des flux métier sensibles, au server-side request forgery (SSRF), aux erreurs de configuration générales et au cross-site scripting (XSS).

Sécurité des API : bonnes pratiques pour les environnements cloud-native. En savoir plus

Bonnes pratiques de sécurité pour GraphQL

Maintenant que nous avons couvert les menaces, découvrez des bonnes pratiques de sécurité des API concrètes pour les backends GraphQL.

Le guide pratique des responsables sécurité

Obtenez des conseils concrets pour aligner équipes, processus et priorités autour d’une stratégie CloudSec efficace.

Votre adresse e-mail professionnelle ici

Télécharger

Cadres d’autorisation et de contrôle d’accès

• Contrôle d’accès au niveau des champs : pour garantir que les utilisateurs consultent ou modifient uniquement les champs autorisés, l’autorisation GraphQL doit s’articuler autour d’un contrôle d’accès au niveau des champs. Appuyez-vous sur des outils comme graphql-shield pour appliquer ces règles à travers les resolvers. Exemple :

const { rule, shield } = require('graphql-shield');

// define a rule to check if the user is an admin
const isAdmin = rule()((parent, args, ctx) => ctx.user.role === 'admin');

// apply the rule to specific fields
const permissions = shield({
  Query: {
    secretData: isAdmin,
  },
});

• Contrôles d’accès contextuels : pour bloquer les accès non autorisés, tenez compte des rôles des utilisateurs, du comportement des requêtes et d’autres informations contextuelles. PRO TIP : LES OUTILS OWASP, COMME L’INQL SCANNER, AIDENT À VALIDER LES FAILLES D’AUTORISATION ET LES CONTRÔLES D’ACCÈS CONTEXTUELS.

• Protections CSRF : les backends GraphQL ont besoin de protections CSRF pour bloquer les requêtes et les mutations non autorisées. Les serveurs doivent refuser toute opération issue d’un navigateur qui n’a pas « préflighté » la requête.

Analyse des requêtes et limitation de l’exécution

Pour maîtriser la complexité des requêtes et prévenir le DoS :

• Assainissez l’entrée utilisateur et toutes les données de requête entrantes afin de repérer les problèmes de sécurité GraphQL dans le corps de la requête. Imposez ensuite des limites de profondeur des requêtes avec des outils comme graphql-depth-limit pour bloquer les requêtes gourmandes en ressources. Exemple :

import express from 'express';
import { createHandler } from 'graphql-http';
import depthLimit from 'graphql-depth-limit';
import { schema } from './schema.js'; // import your GraphQL schema

const app = express();

// register GraphQL middleware for a maximum query depth of 5
app.use(
  '/api/graphql',
  createHandler({
    schema,
    validationRules: [depthLimit(5)],
  })
);

• Pour une sécurité maximale, utilisez des persisted queries ou n’autorisez que certaines requêtes via une allow-list. Cela empêche les attaquants d’envoyer des requêtes totalement arbitraires. Exemple :

POST /api/graphql
{
  "id": "a1b2c3d4",   // hash of the whitelisted query
  "variables": { ... }
}

• Appliquez des contrôles de délai et des limites de ressources à chaque opération. Ainsi, les requêtes légitimes mais coûteuses seront interrompues avant de saturer le serveur, ce qui protège contre les menaces DoS.

Limitation de débit pour GraphQL

Une seule requête peut saturer un serveur. La limitation de débit traditionnelle par adresse IP ou par session utilisateur ne suffit donc pas pour GraphQL. À la place, une limitation de débit GraphQL prête pour la production adopte une approche plus fine, fondée sur l’analyse du coût des requêtes.

Cette méthode attribue un coût à chaque champ pour contrôler la « complexité » qu’un utilisateur consomme par session. La mise en cache réduit encore la charge du serveur et permet des limites de débit globales plus élevées sans nuire aux performances.

Sécurité du schéma

Apollo recommande de toujours désactiver l’introspection GraphQL en production pour empêcher les attaquants d’utiliser le schéma comme feuille de route de reconnaissance.

Autre conseil essentiel : traitez les schémas GraphQL comme un élément fondamental de vos procédures AppSec. Gérez-les avec du version control, documentez-les bien et soumettez-les à des revues fréquentes.

Durcissement général en production

Pour d’autres bonnes pratiques de sécurité des API GraphQL, consultez ces ressources :

• la checklist de préparation à la production d’Apollo ;

• les bonnes pratiques de déploiement d’Apollo ;

• le guide OWASP de sécurité GraphQL ;

• les bonnes pratiques de sécurité de GraphQL.org.

Regarder la démo de 12 minutes

Découvrez toute la puissance de la plateforme de sécurité cloud de Wiz. Elle est conçue pour protéger votre cloud environment, du code à l’exécution. Regarder maintenant

Tester et surveiller les API GraphQL pour détecter les failles de sécurité

Pour une sécurité GraphQL solide, les équipes doivent adopter une approche par couches sur tout le cycle de vie de l’API. Voici quelques repères que vous pouvez suivre :

• Avant le développement :

  • validez les schémas tôt avec des outils comme GraphQL-Inspector et eslint-plugin-graphql ;

  • appliquez le principle of least privilege (PoLP) en concevant des contrôles d’accès au niveau des champs.

• Pendant le développement :

  • intégrez des linters comme GraphQL-ESLint dans l’IDE ;

  • appuyez-vous sur des solutions de software composition analysis (SCA) pour repérer les dependencies vulnérables ;

  • lancez des outils de static application security testing (SAST) pour trouver la logique de resolver non sécurisée.

• Avant le déploiement :

  • employez des outils de dynamic application security testing (DAST) compatibles GraphQL pour découvrir les problèmes à l’exécution ;

  • tirez parti d’un logiciel d’interactive application security testing (IAST) pour repérer les failles à l’exécution.

• Après le déploiement :

  • choisissez une plateforme qui unifie la découverte des API, la surveillance à l’exécution compatible GraphQL et la posture cloud, par exemple le CSPM, pour signaler les erreurs de configuration des serveurs GraphQL et des services cloud environnants ;

  • intégrez des systèmes d’application performance monitoring (APM) et d’observabilité pour suivre les performances et l’usage ;

  • menez régulièrement des campagnes de penetration testing GraphQL pour simuler des attaques réelles et vérifier la réaction de vos défenses ;

  • validez en continu les endpoints de production avec des scans dynamiques sûrs et compatibles GraphQL pour détecter les dérives, comme des champs nouvellement exposés ou une complexité non bornée, ainsi que les régressions.

Comment Wiz sécurise les API GraphQL

Comme nous l’avons vu, l’architecture de GraphQL crée des vecteurs d’attaque uniques : un seul resolver mal configuré ou un endpoint GraphQL mal sécurisé expose toute votre infrastructure à des menaces sérieuses.

Pour GraphQL en particulier, Wiz API Security Posture Management (API SPM) aide les équipes à suivre en continu la posture des API, à valider quels endpoints sont réellement exposés et à relier les faiblesses de schéma ou de resolver aux identités, aux datastores et aux ressources cloud que ces API peuvent atteindre. Ce contexte supplémentaire compte aussi quand un endpoint GraphQL sert de façade à des fonctions d’IA ou à des workflows d’inférence, car un resolver exposé peut aussi exposer l’accès aux modèles ou des données d’entraînement et d’inférence sensibles.

À retenir : pour protéger les backends GraphQL, vous avez besoin d’une solution unifiée comme Wiz.

Wiz Cloud adopte une approche multicouche de la sécurité des API GraphQL :

• Découverte : Wiz API SPM utilise des runtime sensors, des passerelles d’API, des outils de gestion et des spécifications d’API pour découvrir automatiquement vos endpoints GraphQL. Vous maintenez ainsi un inventaire d’API complet et continuellement à jour, y compris les endpoints GraphQL exposés au public par inadvertance.

• Évaluation des risques : avec l’API SPM et le Wiz Dynamic Scanner, Wiz sonde vos endpoints GraphQL pour révéler les erreurs de configuration, les schémas non sécurisés, les failles d’autorisation et d’autres faiblesses d’API, notamment les problèmes alignés sur l’OWASP API Top 10. Wiz valide aussi l’exposition publique et les chemins d’attaque potentiels pour vous aider à comprendre et à prioriser les risques réels.

• Détection des combinaisons toxiques : Wiz va au-delà du scan de surface. En contextualisant les risques d’API avec des caractéristiques comme l’exposition de données sensibles, les flux d’autorisation et les ressources d’hébergement, Wiz identifie les enchaînements de problèmes que les attaquants pourraient exploiter pour compromettre votre infrastructure GraphQL.

Figure 1 : le Wiz Dynamic Scanner en action

En bref, comptez sur Wiz pour :

• un inventaire complet des endpoints d’API ;

• la détection et l’alerte sur l’exposition externe ;

• l’analyse et la validation des schémas GraphQL ;

• la découverte et le scan des données sensibles ;

• le scan des en-têtes d’autorisation ;

• la détection des erreurs de configuration d’autorisation ;

• des métriques de performance et de sécurité des API ;

• la cartographie des ressources d’hébergement ;

• un tableau de bord unifié de sécurité des API.

Voyez-le à l’œuvre : planifiez une démo pour découvrir automatiquement vos endpoints GraphQL, visualiser leur contexte code-to-cloud et prioriser les correctifs qui comptent.

Pour aller plus loin, Voir Wiz en action et découvrez comment sécuriser vos endpoints GraphQL de bout en bout.

Voyez Wiz en action

Découvrez comment Wiz vous aide à identifier les risques critiques et à sécuriser votre cloud plus rapidement.

Adresse e-mail professionnelle*

Prénom*

Nom*

Pays

Numéro de téléphone*

Entreprise*

Je souhaite recevoir des informations sur les nouveaux produits Wiz, les actualités du secteur et l’agenda des événements (vous pouvez vous désabonner à tout moment)

Abonnez-moi aux e-mails de synthèse du blog Wiz

Soumettre

Pour plus d’informations sur la façon dont Wiz traite vos données personnelles, veuillez consulter notre Politique de confidentialité.

Votre adresse e-mail professionnelle ici

Demander une démo

Découverte d’API contextuelle et agentless

Wiz aide les équipes à repérer vite chaque API de leur cloud environment, connue ou inconnue, et à voir son exposition avec tout le contexte d’exécution. La réponse à cette question devient simple : quelles API ai-je, et où s’exécutent-elles ?