Ressources · 37
Sécuriser une API GraphQL : droits, coût des requêtes et preuves
Contrôler chaque objet et champ, borner le travail demandé au serveur et tester les refus.
· 22 min
Ce que ce guide permet
- Cartographier le schéma exposé
- Éprouver les droits
- Borner le coût
- Vérifier les refus
Contrôle express
- Une personne peut-elle lire l’objet d’un autre compte ?
- Un champ sensible suit-il la même décision que son parent ?
- Que coûtent profondeur, alias et pagination combinés ?
- Quels détails fuitent dans les erreurs ?
- Qui voit les refus et les abus ?
Méthode pas à pas
- 01
Inventorier les opérations
Lister types, champs, mutations, rôles, propriétaires des objets et données sensibles. Inclure les requêtes des clients actuels et les chemins rarement appelés.
Livrable : matrice opération, rôle, objet et champ.
- 02
Tester chaque décision de droit
Créer des comptes de test distincts et échanger les identifiants d’objet, y compris dans les objets imbriqués. Le résolveur doit appliquer l’autorisation avant toute réponse.
Livrable : cas autorisés et refusés reproductibles.
- 03
Borner le travail du serveur
Mesurer le coût réel des champs et collections. Tester profondeur, largeur, alias, pagination, lotissement et délais ensemble, puis fixer des limites adaptées.
Livrable : politique de coût et jeu de requêtes adverses.
- 04
Limiter l’exposition inutile
Décider de l’introspection selon le contexte, masquer les détails internes des erreurs et éviter les champs qui révèlent plus que le besoin client.
Livrable : configuration publique et réponses d’erreur revues.
- 05
Observer sans collecter trop
Journaliser identité technique, opération, coût, refus et corrélation utiles, en écartant secrets et arguments sensibles. Définir seuils et propriétaire des alertes.
Livrable : tableau de bord et procédure d’enquête.
- 06
Rejouer après changement
Après ajout de champ, rôle ou client, rejouer les cas de droits et de charge. Vérifier aussi les anciennes requêtes qui traversent le nouveau graphe.
Livrable : résultat de régression et décision de publication.
Indicateurs de pilotage
| Indicateur | Ce qu’il mesure | Première action |
|---|---|---|
| Droits | Cas objet et champ refusés comme prévu | Corriger le résolveur fautif |
| Coût | Requêtes lourdes contenues par la politique | Ajuster champs et limites |
| Erreurs | Réponses publiques sans information interne | Réduire les détails exposés |
| Régression | Opérations clients rejouées après évolution | Bloquer une rupture non prévue |
Erreurs fréquentes
- Faire confiance au seul accès à l’endpoint
- Limiter uniquement la profondeur sans examiner la largeur
- Oublier l’autorisation des champs imbriqués
- Journaliser les arguments contenant des données sensibles
Questions fréquentes
GraphQL remplace-t-il le contrôle de droits REST ?
Non. Chaque accès aux objets et champs doit toujours être autorisé selon l’identité et le contexte.
Désactiver l’introspection suffit-il ?
Non. Cela peut réduire l’exposition du schéma, mais ne corrige ni droits ni coût des requêtes.
Une limite de profondeur suffit-elle ?
Non. Alias, largeur, listes et coûts différents selon les champs doivent aussi être pris en compte.
Références officielles
Pour aller plus loin
Analyses associées
