Jak zabezpieczyć API GraphQL przed nadużywającymi zapytaniami?

Question

IT Interview Practice · Accepted Answer

Elastyczność, która czyni GraphQL potężnym, czyni go też **powierzchnią ataku DoS**: klient może głęboko zagnieździć zapytanie lub poprosić o ogromne listy w jednym wywołaniu. Bronisz się warstwowo — **limity głębokości, analiza złożoności/kosztu, rate limiting i poprawna autoryzacja** — a żadnej z tych rzeczy język zapytań nie wymusza za ciebie.

## Zagrożenie: nieograniczone zapytania

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

## Obrona

- **Limitowanie głębokości** — odrzucaj zapytania zagnieżdżone powyżej, powiedzmy, 7 poziomów. Tania pierwsza linia obrony.
- **Analiza kosztu/złożoności** — przypisz każdemu polu koszt, waż pola listowe ich argumentem `first` i odrzucaj przed wykonaniem, jeśli suma przekracza budżet. Silniejsze niż surowa głębokość, bo uwzględnia szerokość list.
- **Rate limiting** — budżety per klient, najlepiej oparte na **koszcie zapytania** (nie tylko liczbie żądań), tak by jedno kosztowne zapytanie liczyło się jak wiele.
- **Persisted/allow-listed queries** — na produkcji akceptuj tylko wcześniej zarejestrowany zestaw zapytań; dowolne zapytania ad-hoc są odrzucane, co eliminuje większość wektorów 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
  ],
});
```

## Autoryzacja

Uwierzytelnij raz (zweryfikuj token w `context`), a następnie **autoryzuj per pole/resolver** — nigdy nie ufaj, że klient pominie pola. Wykonuj sprawdzenia w resolverach lub warstwie takiej jak GraphQL Shield i **nigdy nie ujawniaj schematu introspekcji** ani rozwlekłych stack trace na produkcji.

## Dlaczego to ważne

Endpointy REST są naturalnie ograniczone; pojedyncze zapytanie GraphQL nie jest. Senior rekruterzy chcą usłyszeć nastawienie **oparte na koszcie** — głębokość jest konieczna, ale niewystarczająca, analiza złożoności plus persisted queries to prawdziwa odpowiedź — oraz dyscyplinę autoryzacji per resolver.

Zagrożenie: nieograniczone zapytania

Obrona

Autoryzacja

Dlaczego to ważne

Powiązane pytania