Comment sécuriser une API GraphQL contre les requêtes abusives ?

Question

IT Interview Practice · Accepted Answer

La flexibilité qui rend GraphQL puissant en fait aussi une **surface de DoS** : un client peut imbriquer une requête en profondeur ou demander d'énormes listes en un seul appel. Vous vous défendez en couches — **limites de profondeur, analyse de complexité/coût, rate limiting et auth correcte** — dont aucune n'est imposée par le langage de requête lui-même.

## La menace : les requêtes non bornées

```graphql
# Une requête cyclique malveillante : chaque niveau multiplie le travail de façon exponentielle
query Bomb {
  user { friends { friends { friends { friends { name } } } } }
}
```

## Défenses

- **Limitation de profondeur** — rejeter les requêtes imbriquées au-delà de, disons, 7 niveaux. Première ligne de défense peu coûteuse.
- **Analyse de coût/complexité** — affecter un coût à chaque champ, pondérer les champs liste par leur argument `first`, et rejeter avant exécution si le total dépasse un budget. Plus robuste que la seule profondeur, car elle tient compte de la largeur des listes.
- **Rate limiting** — des budgets par client, idéalement sur le **coût des requêtes** (pas seulement le nombre de requêtes), afin qu'une requête coûteuse compte pour plusieurs.
- **Persisted queries / allow-list** — en production, n'accepter qu'un ensemble de requêtes pré-enregistrées ; les requêtes ad hoc arbitraires sont refusées, ce qui élimine la plupart des vecteurs d'injection/DoS.

```js
import depthLimit from "graphql-depth-limit";
import costAnalysis from "graphql-cost-analysis";

const server = new ApolloServer({
  schema,
  validationRules: [
    depthLimit(7),                                  // bloque l'imbrication profonde
    costAnalysis({ maximumCost: 1000 }),            // bloque avant exécution les requêtes larges/coûteuses
  ],
});
```

## Auth

Authentifiez une seule fois (validez le token dans le `context`), puis **autorisez par champ/resolver** — ne faites jamais confiance au client pour omettre des champs. Effectuez les vérifications dans les resolvers ou une couche comme GraphQL Shield, et **n'exposez jamais le schéma d'introspection** ni des stack traces verbeuses en production.

## Pourquoi c'est important

Les endpoints REST sont naturellement bornés ; une seule requête GraphQL ne l'est pas. Les recruteurs seniors attendent l'état d'esprit **basé sur le coût** — la profondeur est nécessaire mais insuffisante, l'analyse de complexité plus les persisted queries sont la vraie réponse — ainsi que la discipline de l'autorisation par resolver.

La menace : les requêtes non bornées

Défenses

Auth

Pourquoi c'est important

Questions connexes