Hur säkrar du ett GraphQL-API mot missbrukande frågor?

Question

IT Interview Practice · Accepted Answer

Flexibiliteten som gör GraphQL kraftfullt gör det också till en **DoS-yta**: en klient kan nästla en fråga djupt eller begära enorma listor i ett enda anrop. Du försvarar dig i lager — **djupbegränsningar, komplexitets-/kostnadsanalys, rate limiting och korrekt autentisering** — inget av vilket frågespråket upprätthåller åt dig.

## Hotet: obegränsade frågor

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

## Försvar

- **Djupbegränsning** — avvisa frågor som är nästlade bortom, säg, 7 nivåer. En billig första försvarslinje.
- **Kostnads-/komplexitetsanalys** — tilldela varje fält en kostnad, vikta listfält efter deras `first`-argument, och avvisa innan exekvering om summan överskrider en budget. Starkare än enbart djup eftersom det tar hänsyn till listornas bredd.
- **Rate limiting** — budgetar per klient, helst baserat på **frågekostnad** (inte bara antal förfrågningar), så att en dyr fråga räknas som många.
- **Persisted/allow-listade frågor** — i produktion, acceptera endast en förregistrerad uppsättning frågor; godtyckliga ad hoc-frågor avvisas, vilket eliminerar de flesta injektions-/DoS-vektorer.

```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
  ],
});
```

## Autentisering

Autentisera en gång (validera token i `context`), och **auktorisera sedan per fält/resolver** — lita aldrig på att klienten utelämnar fält. Gör kontroller i resolvers eller ett lager som GraphQL Shield, och **exponera aldrig introspektionsschemat** eller utförliga stackspårningar i produktion.

## Varför det är viktigt

REST-endpoints är naturligt begränsade; en enskild GraphQL-fråga är det inte. Senior-intervjuare vill se det **kostnadsbaserade** tankesättet — djup är nödvändigt men otillräckligt, komplexitetsanalys plus persisted queries är det verkliga svaret — och disciplinen med auktorisering per resolver.

Hotet: obegränsade frågor

Försvar

Autentisering

Varför det är viktigt

Relaterade frågor