Come si protegge un'API GraphQL dalle query abusive?

Question

IT Interview Practice · Accepted Answer

La flessibilità che rende GraphQL potente lo rende anche una **superficie di attacco DoS**: un client può annidare profondamente una query o richiedere liste enormi in una sola chiamata. Ci si difende a livelli — **limiti di profondità, analisi di complessità/costo, rate limiting e autenticazione corretta** — nessuno dei quali è imposto per te dal linguaggio di query.

## La minaccia: query illimitate

```graphql
# A malicious cyclic query: each level multiplies the work exponentially
query Bomb {
  user { friends { friends { friends { friends { name } } } } }
}
```

## Difese

- **Limitazione della profondità** — rifiuta le query annidate oltre, poniamo, 7 livelli. Prima linea di difesa economica.
- **Analisi di costo/complessità** — assegna a ogni campo un costo, pesa i campi lista in base al loro argomento `first` e rifiuta prima dell'esecuzione se il totale supera un budget. Più forte della profondità grezza perché tiene conto dell'ampiezza delle liste.
- **Rate limiting** — budget per client, idealmente sul **costo della query** (non solo sul numero di richieste), così una query costosa conta come molte.
- **Persisted/allow-listed query** — in produzione, accetta solo un insieme pre-registrato di query; le query ad-hoc arbitrarie vengono rifiutate, eliminando la maggior parte dei vettori di injection/DoS.

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

const server = new ApolloServer({
  schema,
  validationRules: [
    depthLimit(7),                                  // block deep nesting
    costAnalysis({ maximumCost: 1000 }),            // block broad/expensive queries pre-execution
  ],
});
```

## Autenticazione

Autentica una volta (valida il token nel `context`), poi **autorizza per campo/resolver** — non fidarti mai del fatto che il client ometta dei campi. Esegui i controlli nei resolver o in un livello come GraphQL Shield, e **non esporre mai lo schema di introspezione** né stack trace verbose in produzione.

## Perché è importante

Gli endpoint REST sono naturalmente limitati; una singola query GraphQL non lo è. Gli intervistatori senior vogliono la mentalità **basata sul costo** — la profondità è necessaria ma insufficiente, l'analisi di complessità più le persisted query è la vera risposta — e la disciplina dell'autorizzazione per resolver.

La minaccia: query illimitate

Difese

Autenticazione

Perché è importante

Domande correlate