Miten GraphQL-API suojataan väärinkäyttäviltä kyselyiltä?

Question

IT Interview Practice · Accepted Answer

Se joustavuus, joka tekee GraphQL:stä tehokkaan, tekee siitä myös **DoS-pinnan**: client voi sisäkkäistää kyselyn syvälle tai pyytää valtavia listoja yhdessä kutsussa. Puolustaudut kerroksittain — **syvyysrajat, monimutkaisuus-/kustannusanalyysi, rate limiting ja kunnollinen auth** — mistään näistä kyselykieli ei huolehdi puolestasi.

## Uhka: rajoittamattomat kyselyt

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

## Puolustukset

- **Syvyysrajoitus** — hylkää kyselyt, jotka on sisäkkäistetty esimerkiksi yli 7 tasoa. Halpa ensimmäinen puolustuslinja.
- **Kustannus-/monimutkaisuusanalyysi** — anna jokaiselle kentälle kustannus, painota listakenttiä niiden `first`-argumentilla ja hylkää ennen suoritusta, jos kokonaissumma ylittää budjetin. Vahvempi kuin pelkkä syvyys, koska se ottaa huomioon listojen leveyden.
- **Rate limiting** — clientkohtaiset budjetit, ihanteellisesti **kyselyn kustannuksen** perusteella (ei vain pyyntöjen lukumäärän), jotta yksi kallis kysely lasketaan monena.
- **Persisted/allow-listatut kyselyt** — tuotannossa hyväksy vain ennalta rekisteröity joukko kyselyitä; mielivaltaiset ad hoc -kyselyt hylätään, mikä eliminoi useimmat injektio-/DoS-vektorit.

```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

Autentikoi kerran (validoi token `context`issa), sitten **autorisoi kenttä-/resolverkohtaisesti** — älä koskaan luota siihen, että client jättää kentät pois. Tee tarkistukset resolvereissa tai kerroksessa kuten GraphQL Shield, äläkä **koskaan paljasta introspection-schemaa** tai monisanaisia stack traceja tuotannossa.

## Miksi se on tärkeää

REST-endpointit ovat luonnostaan rajattuja; yksittäinen GraphQL-kysely ei ole. Senior-haastattelijat haluavat **kustannuspohjaisen** ajattelutavan — syvyys on välttämätön mutta riittämätön, monimutkaisuusanalyysi plus persisted queryt on todellinen vastaus — ja resolverkohtaisen autorisoinnin kurinalaisuuden.

Uhka: rajoittamattomat kyselyt

Puolustukset

Auth

Miksi se on tärkeää

Aiheeseen liittyvät kysymykset