Comment empêchez-vous les attaques imbriquées sur le serveur GraphQL / Apollo?

Au moment de l'écriture, il n'y a pas de fonctionnalité intégrée dans GraphQL-js ou Apollo Server pour gérer cette préoccupation, mais c'est quelque chose qui devrait certainement avoir une solution simple car GraphQL devient plus populaire. Ce problème peut être résolu avec plusieurs approches à plusieurs niveaux de la pile, et devrait également toujours être combiné avec la limitation de débit, de sorte que les gens ne puissent pas envoyer trop de requêtes à votre serveur (c'est aussi un problème potentiel avec REST).

Je vais juste énumérer tout les différentes méthodes auxquelles je peux penser, et je vais essayer de garder cette réponse à jour car ces solutions sont implémentées dans divers serveurs GraphQL. Certains d'entre eux sont assez simples, et certains sont plus complexes.

1. Query validation : dans chaque serveur GraphQL, la première étape pour exécuter une requête est validation - c'est là que le serveur essaie de déterminer s'il y a des erreurs graves dans la requête, afin que nous puissions éviter d'utiliser les ressources réelles du serveur si nous pouvons trouver cela il y a une erreur de syntaxe ou un argument invalide à l'avant. GraphQL-JS est livré avec une sélection de règles par défaut qui suivent un format assez similaire à ESLint. Tout comme il existe une règle pour détecter cycles infinis en fragments , on pourrait écrire une règle de validation pour détecter les requêtes avec trop d'imbrication et les rejeter au stade de la validation.
2. Délai D'attente de la requête : S'il n'est pas possible de détecter qu'une requête consomme trop de ressources statiquement (peut-être même les requêtes superficielles peuvent être très coûteuses!), alors nous pouvons simplement ajouter un délai d'attente à l'exécution de la requête. Cela a quelques avantages: (1) c'est une limite difficile qui n'est pas trop difficile à raisonner, et (2) cela aidera également dans les situations où l'un des backends prend excessivement longtemps pour répondre. Dans de nombreux cas, un utilisateur de votre application préférez un champ manquant plus d'attendre 10 secondes pour obtenir une réponse.
3. Query whitelisting : c'est probablement la méthode la plus impliquée, mais vous pourriez compilez une liste des requêtes autorisées à l'avance et vérifiez toutes les requêtes entrantes par rapport à cette liste. Si vos requêtes sont totalement statiques (vous ne faites aucune génération de requête dynamique sur le client avec quelque chose comme Relay), c'est l'approche la plus fiable. Vous pouvez utiliser un outil automatisé pour extraire des chaînes de requête de vos applications lorsqu'elles sont déployées, de sorte que dans le développement, vous écrivez toutes les requêtes que vous voulez, mais en production, seules celles que vous voulez sont laissées. Un autre avantage de cette approche est-ce que vous pouvez ignorer entièrement la validation de la requête, puisque vous savez que toutes les requêtes possibles sont déjà valides. Pour plus d'avantages des requêtes statiques et des listes blanches, lisez cet article: https://dev-blog.apollodata.com/5-benefits-of-static-graphql-queries-b7fa90b0b69a
4. limitation des coûts de requête : (ajouté dans une édition) similaire aux délais d'attente de requête, vous pouvez affecter un coût à différentes opérations lors de l'exécution de la requête, par exemple une requête de base de données, et limiter le coût total du client est en mesure d'utiliser par requête. Cela peut être combiné avec la limitation du parallélisme maximal d'une seule requête, de sorte que vous pouvez empêcher le client d'envoyer quelque chose qui initie des milliers de requêtes parallèles à votre backend.

(1) et (2) en particulier sont probablement quelque chose que chaque serveur GraphQL devrait avoir par défaut, d'autant plus que de nombreux nouveaux développeurs pourraient ne pas être au courant de ces préoccupations. (3) ne fonctionnera que pour certains types d'applications, mais pourrait être un bon choix quand il sont des exigences de performance ou de sécurité très strictes.