Retour au centre d’apprentissage

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

La sécurité des API GraphQL est l’ensemble des pratiques et des technologies utilisées pour protéger les API GraphQL contre les accès non autorisés, les requêtes malveillantes, l’exposition des données, les attaques par déni de service et les abus.

GraphQL, qui est un langage de requête open source, offre aux clients (ordinateurs, téléphones, ou navigateurs, programmes logiciel) une flexibilité considérable quant aux données qu’ils demandent. Plutôt que de s’appuyer sur des points de terminaison prédéfinis qui renvoient des réponse fixes, les clients peuvent construire des requête qui spécifient les champs et les données associées dont ils ont besoin.

Cette flexibilité peut rendre les API plus efficaces pour les développeurs, mais elle introduit également des considérations de sécurité distinctes. Une API GraphQL mal protégée peut permettre à des hackers de construire des requêtes coûteuses en calcul, de découvrir des parties sensibles d’un schéma d’API, d’accéder à des données qu’ils ne sont pas autorisés à voir, ou d’automatiser un grand nombre de requêtes malveillantes.

Une sécurité GraphQL efficace nécessite donc une combinaison d’authentification, d’autorisation, de contrôle des requêtes, de validation des entrées, de limitation du débit, de sécurité des applications, de surveillance et de design d’API sécurisé.

Quels outils et pratiques composent la sécurité des API GraphQL ?

La sécurité des API GraphQL protège les données, les opérations et l’infrastructure exposées via une API GraphQL. Une API GraphQL expose généralement un schéma, décrivant les types de données disponibles et les opérations que les clients peuvent effectuer. Les clients envoient des requêtes ou des mutations décrivant les informations ou les actions qu’ils souhaitent.

La protection des API GraphQL implique des pratiques et des outils autour de 

L’objectif est de fournir aux clients légitimes les capacités dont ils ont besoin, sans restreindre la flexibilité de GraphQL. 

Comment fonctionne la sécurité des API GraphQL ?

Une requête GraphQL atteint généralement un seul point de terminaison HTTP, comme « /graphql ». La requête contient une requête décrivant l’opération que le client souhaite que le serveur effectue.Un client légitime peut demander des informations sur un produit et sa disponibilité. 

Le serveur GraphQL analyse la requête, la valide par rapport au schéma, invoque les résolveurs nécessaires, récupère les données appropriées et renvoie une réponse.

Des contrôles de sécurité peuvent être appliqués à plusieurs étapes de ce processus. 

L’authentification identifie le client

L’authentification détermine qui ou quoi effectue la requête. Les API GraphQL peuvent utiliser des mécanismes comme les cookies de session, les clés API, OAuth ou les JSON Web jetons (JWT), selon l’architecture de l’application.

L’autorisation contrôle ce que le client peut faire

L’authentification seule ne suffit pas. Après avoir identifié le client, l’application doit déterminer si cette identité est autorisée à accéder à un objet, un champ ou une opération en particulier.

L’autorisation doit être appliquée dans la couche de logique métier, plutôt que de s’appuyer uniquement sur les résolveurs GraphQL ou de masquer des parties du schéma. 

Les contrôles de requête limitent les opérations coûteuses

Les requêtes GraphQL peuvent être imbriquées. Sans contrôle approprié, un client peut soumettre une requête qui nécessite une charge importante de CPU, de mémoire, de base de données, ou des appels à des services en aval.

Les applications peuvent analyser la profondeur, l’étendue, la complexité ou le coût des requêtes, et rejeter les requêtes qui dépassent les limites acceptables.

Les contrôles de limitation du débit régulent la consommation de requêtes

Les rate limits (limitations du débit) peuvent contrôler la fréquence à laquelle les clients effectuent des Opérations. Pour GraphQL, les organisations peuvent avoir besoin de contrôle plus sophistiqués que le simple comptage des requête HTTP, car deux requête vers le même point de terminaison /graphql peuvent avoir des coûts de calcul radicalement différents.

Les contrôles de sécurité des applications inspectent le trafic malveillant

Un pare-feu d’application web (WAF) ou une plateforme de Web Application and API Protection (WAAP) peut inspecter les requêtes pour détecter des attaques comme l’injection et d’autres charges utiles malveillantes avant qu’elles n’atteignent l’application GraphQL.

La surveillance détecte un comportement inhabituel

Les logs et la télémétrie de sécurité peuvent révéler des schémas de requêtes inattendus, des échecs d’autorisation répétés, des requêtes inhabituellement coûteuses, des bots malveillants, ou des pics de trafic. Ensemble, ces contrôles assurent une défense en profondeur autour de l’API GraphQL.

Pourquoi la sécurité des API GraphQL est-elle nécessaire ?

GraphQL ne rend pas intrinsèquement une API non sécurisée. Cependant, certaines des fonctionnalités qui font la puissance de GraphQL créent également des considérations de sécurité qui diffèrent de celles des API REST conventionnelles. 

Voici les risques introduits par la nature de GraphQL, et les raisons pour lesquelles la sécurité des API GraphQL est si importante. 

Les clients ont un contrôle important sur les requêtes

Avec une API REST, le serveur définit généralement des points de terminaison qui renvoient des structures de données prédéterminées. À la place, GraphQL permet au client de spécifier les champs et les relations qu’il souhaite. Sans restrictions appropriées, un client malveillant peut potentiellement exploiter cette flexibilité pour construire des requêtes coûteuses ou abusives.

Un seul point de terminaison peut exposer de nombreuses opérations

La sécurité des API traditionnelle utilise souvent les chemins d’URL comme élément important de la politique de sécurité. GraphQL achemine couramment de nombreuses requêtes et mutations différentes via le même point de terminaison. Un système de sécurité ne peut donc pas supposer que toutes les requêtes vers /graphql représentent la même opération ou le même risque.

Les requêtes peuvent devenir coûteuses en calcul

GraphQL permet des relations imbriquées. Une requête profondément imbriquée ou exceptionnellement large peut entraîner de nombreux appels de résolveur, des Opérations de base de données, ou des requêtes en aval. Les hackers peuvent intentionnellement exploiter ce comportement pour consommer les ressources de l’application.

L’autorisation peut devenir granulaire

Un utilisateur peut être autorisé à accéder à un objet GraphQL, mais pas à un autre, ou à certains champs d’un objet, mais pas à d’autres. Chaque opération pertinente d’accès aux données nécessite donc une autorisation appropriée.

Les informations de schéma peuvent aider les hackers

GraphQL prend en charge l’introspection, ce qui permet aux clients d’effectuer une requête d’informations sur le schéma. Cela est extrêmement utile pour les outils de développement. En production, toutefois, les organisations doivent prendre une décision réfléchie quant à la nécessité d’une introspection sans restriction, car les informations sur le schéma peuvent aider les hackers à comprendre les Opérations disponibles.

Les API attirent les abus automatisés

Des hackers peuvent utiliser des bots pour effectuer de la reconnaissance, des attaques d’identifiants, interroger des Opérations coûteuses, extraire des données, ou tenter une exploitation à l’échelle. La sécurité de GraphQL doit donc prendre en compte à la fois les vulnérabilités, et l’abus de fonctionnalité légitime.

Quels sont les risques courants liés à la sécurité des API GraphQL ?

Autorisation défaillante

Une API peut authentifier correctement un utilisateur, mais ne pas vérifier si cet utilisateur doit être autorisé à accéder à un objet ou à un champ particulier. Par exemple, modifier un identifiant d’objet dans une requête ne devrait pas permettre à un client de récupérer les informations privées d’un autre client.

Profondeur de requête excessive

Un hacker peut construire des requêtes profondément imbriquées qui nécessitent des quantités de traitement de plus en plus importantes. Les limites de profondeur peuvent empêcher les requêtes de dépasser les exigences raisonnables d’imbrication d’une application.

Complexité des requêtes et épuisement des ressources

La profondeur n’est pas la seule préoccupation - une requête relativement peu profonde pourrait demander des milliers d’objets ou invoquer des résolveurs coûteux. L’analyse du coût ou de la complexité des requêtes peut offrir une protection plus précise en estimant les ressources nécessaires à l’exécution d’une requête.

Abus de traitement par lots

Les implémentations GraphQL peuvent permettre l’envoi groupé de plusieurs opérations. Bien que le traitement par lots puisse améliorer l’efficacité légitime de l’application, des hackers peuvent tenter de l’utiliser pour contourner de simples rate limits (limitation du débit) basées sur les requêtes ou effectuer un grand nombre d’opérations dans un nombre réduit de requêtes HTTP.

attaque par injection

Les résolveurs GraphQL interagissent fréquemment avec des bases de données, et d’autres systèmes back-end. Si les entrées utilisateur sont traitées de manière non sécurisée en aval, les application GraphQL peuvent toujours être vulnérables à l’injection SQL, à l’injection de commandes, et à d’autres attaque par injection.

Divulgation d’informations

Des erreurs détaillées peuvent exposer des traces de pile, des détails d’implémentation internes, ou d’autres informations utiles aux hackers. L’introspection du schéma peut également divulguer des informations sur les types et les Opérations disponibles lorsqu’elle est activée.

Déni de service

Des requêtes coûteuses, des alias excessifs, le traitement par lots, des requêtes répétées ou d’autres opérations gourmandes en ressources peuvent être utilisés pour dégrader les performances ou la disponibilité de l’application.

Scraping automatisé et abus

Une requête GraphQL techniquement valide peut néanmoins être abusive lorsqu’elle est exécutée automatiquement à grande échelle. Le Bot Management et la limitation du débit peuvent être des compléments importants à une sécurité des API axée sur les vulnérabilités.

Quelles sont les bonnes pratiques en matière de sécurité des API GraphQL ?

La sécurité de GraphQL doit commencer par l’application elle-même et être renforcée par des contrôles de sécurité à la durée d’exécution.

1. Exiger une authentification forte

Protégez les opérations non publiques avec des mécanismes d’authentification appropriés. Utilisez des normes d’identité établies et une gestion sécurisée des sessions ou des jetons plutôt que de créer des schémas d’authentification personnalisés sans raison impérieuse.

2. Appliquer l’autorisation à chaque couche pertinente

Ne supposez pas que les utilisateurs authentifiés doivent avoir accès à chaque objet exposé via le schéma. L’autorisation doit être liée aux règles métier de l’application et appliquée de manière cohérente lorsque les données sont consultées ou modifiées.

3. Limitent la profondeur des requêtes

Définissez des limite raisonnables quant au niveau d’imbrication des requête. Le maximum approprié dépend des exigences légitimes de l’application.

4. Mettre en œuvre l’analyse du coût des requêtes

Attribuez des coûts aux champs ou aux Opérations en fonction de leur consommation de ressources attendue, et rejetez les requête dont le coût calculé dépasse un seuil acceptable. Cela peut offrir une protection plus pertinente que les limite de profondeur à elles seules.

5. Appliquez des rate limits (limitations du débit)

Appliquez une rate limit (limitation du débit) aux clients en fonction du risque de l’application et des schémas d’utilisation normaux. Lorsque cela est possible, tenez compte du coût réel de l’opération GraphQL ou de la ressource, plutôt que de considérer chaque requête HTTP comme équivalente.

6. Contrôle du traitement par lots et des alias

Définissez des limites raisonnables quant au nombre d’opérations, d’alias ou de champs qu’un client peut faire une requête à la fois. Cela peut réduire les possibilités de contourner les rate limit (limitation du débit) conventionnelles ou de créer des charges de travail d’un coût inattendu.

7. Validez toutes les entrées

Traitez les arguments GraphQL comme des entrées non fiables. Utilisez la validation de schéma, des requêtes de base de données paramétrées, des API sûres, et une gestion de sortie adaptée au contexte.

8. Prendre une décision réfléchie concernant l’introspection

L’introspection est utile pour le développement et les outils, mais l’accès en production doit correspondre aux exigences de l’organisation. La désactivation ou la restriction de l’introspection ne remplace pas l’autorisation, mais peut réduire l’exposition inutile d’informations.

9. Évitez les détails d’erreur excessifs

Renvoyez des erreurs utiles aux clients légitimes, sans exposer les traces de pile, les informations de base de données, les détails des services internes, ou d’autres informations d’implémentation sensibles.

10. Utiliser des délais d’expiration

Les requêtes ne devraient pas être autorisées à consommer indéfiniment les ressources du serveur. Des délais d’expiration appropriés pour l’exécution, la base de données, et les services en aval peuvent limiter l’impact d’Opérations dont le coût est inopinément élevé.

11. Protéger le point de terminaison GraphQL avec un WAF

Un WAF peut fournir une couche de sécurité supplémentaire contre les requêtes d’application malveillantes. Il ne doit pas remplacer une conception GraphQL sécurisée, mais il peut aider à empêcher les attaques d’atteindre des composants d’application vulnérables.

12. Surveiller le trafic GraphQL

Suivez les taux de requêtes, les erreurs, les échecs d’authentification, les modèles d’opération, la complexité des requêtes, la latence du back-end et la consommation des ressources. Une observabilité efficace facilite l’identification des attaques et des problèmes de performances avant qu’ils n’affectent significativement les utilisateur.

Qui a besoin de sécurité des API GraphQL ?

Toute organisation exposant des API GraphQL devrait mettre en œuvre des contrôles de sécurité appropriés, mais ce besoin devient particulièrement important pour les API qui traitent des données sensibles, de grands volumes de trafic, ou des opérations commerciales précieuses.

Fournisseurs Logiciel en tant que service

GraphQL peut permettre aux applications front-end de récupérer efficacement des données complexes sur les clients et les application. Une autorisation forte est essentielle dans les environnements multi-client pour empêcher les données de franchir les limites entre clients.

Entreprises d’e-commerce

Les API GraphQL peuvent exposer des catalogues de produits, des comptes client, des paniers, des stocks, la fonctionnalité de paiement, et d’autres Opérations à forte valeur. Ces API peuvent attirer le scraping, les attaques par identifiants, la fraude, et les attaques contre la disponibilité.

Services financiers

Les API qui traitent des informations financières ou personnelles nécessitent une authentification forte, une autorisation, une surveillance, et une prévention des abus.

Médias et entreprises d’édition

GraphQL peut fournir un accès flexible à de grandes bibliothèques de contenu, mais peut aussi devenir une cible pour le scraping non autorisé et les requêtes gourmandes en ressources.

Développeurs mobiles et d’applications

GraphQL est utile lorsque différents clients ont besoin de différents sous-ensembles de données. Les applications mobiles communiquent toujours avec des API accessibles publiquement, de sorte qu’un hacker peut potentiellement interagir directement avec l’API plutôt qu’en utilisant l’application officielle.

Les entreprises utilisant des microservice

GraphQL peut fournir une couche API unifiée sur plusieurs services back-end. Cela rend la sécurité particulièrement importante, car une interface GraphQL peut fournir un accès à des données et à des fonctionnalités réparties sur de nombreux systèmes internes.

Comment Fastly peut-il aider à protéger les API GraphQL ?

Fastly fournit plusieurs capacités de sécurité qui peuvent compléter les contrôle mis en œuvre au sein d’une application GraphQL.

Fastly Next-Gen WAF

Fastly Next-Gen WAF protège les applications web et les API contre les requêtes malveillantes. Il utilise la technologie de détection SmartParse de Fastly pour analyser les paramètres de requête et identifier le comportement malveillant des applications plutôt que de dépendre exclusivement de la correspondance traditionnelle par expression régulière.

Cela peut fournir une couche de protection supplémentaire contre les attaques par injection et d’autres attaques ciblant les API GraphQL au niveau de la couche d'application.

Fonctionnalités de sécurité des API Fastly

Les capacités de Fastly en matière d’application web et de Protection des API peuvent aider les organisations à protéger les API, ainsi que les applications web traditionnelles. Le fait de placer la sécurité en périphérie permet d’inspecter les requêtes malveillantes avant qu’elles ne consomment les ressources de l’application GraphQL, de la base de données, ou des services back-end.

Cela est particulièrement utile dans les architectures GraphQL, où une requête peut potentiellement déclencher un travail en aval considérable.

Fastly Bot Management

Une requête GraphQL n’a pas besoin d’exploiter une vulnérabilité pour causer des dommages. Des hackers peuvent utiliser des clients automatisés pour extraire des données, sonder des schémas et des Opérations, tenter des attaques de compte, ou invoquer de manière répétée des requêtes coûteuses.

Fastly Bot Management aide à identifier et à gérer le trafic automatisé afin que les organisations puissent appliquer un contrôle approprié aux bots indésirables tout en préservant l’accès pour les utilisateurs légitimes et l’automatisation approuvée.

Limitation du débit

Les capacités de limitation du débit de Fastly peuvent aider à contrôler le trafic excessif avant qu’il n’atteigne les application protégées. Pour les environnements GraphQL, la limitation du débit en périphérie peut compléter les contrôle au niveau de l’application, comme l’analyse du coût des requêtes. La périphérie peut restreindre l’activité excessive des requêtes tandis que le serveur GraphQL applique des politiques plus détaillées en fonction du coût réel et des exigences d’autorisation de chaque opération.

Protection DDoS

Les points de terminaison GraphQL peuvent devenir des cibles pour des attaques par déni de service distribué au niveau de la couche d’application, en particulier lorsque des hackers identifient des requêtes qui consomment des ressources de back-end disproportionnées. Protection DDoS peut aider à détecter et à atténuer le trafic malveillant en périphérie, réduisant la quantité de trafic d’attaque atteignant l’infrastructure de l’application.

Distribution en périphérie et mise en cache

Lorsque les réponse GraphQL peuvent être mise en cache possible en toute sécurité, les capacités de distribution de Fastly peuvent réduire les requête répétées vers l’infrastructure GraphQL. La mise en cache de GraphQL nécessite une conception minutieuse, car les réponse peuvent dépendre des requêtes, des variables, de l’authentification, et des données spécifiques à l’utilisateur. Les organisations ne devraient mettre en cache les réponses que lorsque les clés de cache et les politiques représentent fidèlement ces variations.

Lorsqu’elle est mise en œuvre de manière appropriée, la mise en cache en périphérie peut réduire les requête vers le back-end et améliorer les performances API.

Visibilité en temps réel

Fastly fournit une journalisation en temps réel et une visibilité sur la sécurité qui peuvent aider les équipes à enquêter sur une activité API suspecte. Pour les déploiements GraphQL, cela peut compléter l’observabilité au niveau de l’application en donnant aux équipes de sécurité et d’Opérations une visibilité sur le trafic avant qu’il n’atteigne le service GraphQL.

Comment Fastly s’intègre-t-il dans une stratégie de sécurité GraphQL ?

Fastly est mieux considéré comme une couche de sécurité supplémentaire autour d’une application GraphQL correctement sécurisée, et non comme un remplacement de la sécurité au sein de l’implémentation GraphQL.

L’application doit rester responsable des contrôle, notamment :

  • Authentification

  • Autorisation au niveau des objets et des champs

  • Limites de profondeur des requêtes

  • Analyse de la complexité ou du coût des requêtes

  • Mise en œuvre sécurisée du résolveur

  • Validation des entrées

  • Gestion sécurisée des erreurs

  • Politiques d’introspection appropriées

Fastly peut compléter ces contrôle avec Next-Gen WAF, Protection des API, Bot Management, limitation du débit, Protection DDoS, distribution en périphérie, et visibilité en temps réel.

Ensemble, ces couches peuvent aider les organisations à bloquer les requêtes malveillantes avant qu’elles n’atteignent l’infrastructure GraphQL, à contrôler les abus automatisés, à réduire l’impact des pics de trafic, à protéger les API contre les attaques d’application, et à limiter la consommation inutile des ressources du back-end.

Le principe central de la sécurité des API GraphQL consiste à préserver la flexibilité de GraphQL sans donner aux clients un contrôle illimité sur les ressources ou les données de l’application. La combinaison d’une conception GraphQL sécurisée avec une protection des applications et des API basée sur la périphérie peut aider les organisations à atteindre cet équilibre.


Prêt à commencer ?

Contactez-nous dès aujourd’hui
Parler à un expert