Hvordan sikrer du et GraphQL-API mod misbrugende forespørgsler?

Question

IT Interview Practice · Accepted Answer

Fleksibiliteten, der gør GraphQL kraftfuld, gør det også til en **DoS-overflade**: en klient kan indlejre en forespørgsel dybt eller anmode om enorme lister i ét kald. Du forsvarer i lag — **depth limits, complexity/cost-analyse, rate limiting og korrekt auth** — hvoraf ingen håndhæves for dig af forespørgselssproget.

## Truslen: ubegrænsede forespørgsler

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

## Forsvar

- **Depth limiting** — afvis forespørgsler indlejret dybere end fx 7 niveauer. Billig første forsvarslinje.
- **Cost/complexity-analyse** — tildel hvert felt en omkostning, vægt list-felter efter deres `first`-argument, og afvis før eksekvering, hvis totalen overstiger et budget. Stærkere end ren depth, fordi den tager højde for listers bredde.
- **Rate limiting** — per-klient-budgetter, ideelt på **forespørgselsomkostning** (ikke blot antal requests), så én dyr forespørgsel tæller som mange.
- **Persisted/allow-listede queries** — i produktion accepteres kun et forudregistreret sæt af forespørgsler; vilkårlige ad hoc-forespørgsler afvises, hvilket eliminerer de fleste injection/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
  ],
});
```

## Auth

Autentificér én gang (validér tokenet i `context`), og **autorisér derefter per felt/resolver** — stol aldrig på, at klienten udelader felter. Foretag tjek i resolvers eller et lag som GraphQL Shield, og **eksponer aldrig introspection-skemaet** eller detaljerede stack traces i produktion.

## Hvorfor det betyder noget

REST-endpoints er naturligt begrænsede; en enkelt GraphQL-forespørgsel er det ikke. Senior-interviewere vil have den **omkostningsbaserede** tankegang — depth er nødvendig, men utilstrækkelig, complexity-analyse plus persisted queries er det egentlige svar — og disciplinen med per-resolver-autorisation.

Truslen: ubegrænsede forespørgsler

Forsvar

Auth

Hvorfor det betyder noget

Relaterede spørgsmål