악의적인 쿼리로부터 GraphQL API를 어떻게 보호하나요?

Question

IT Interview Practice · Accepted Answer

GraphQL을 강력하게 만드는 유연성은 동시에 그것을 **DoS 표면**으로 만듭니다: 클라이언트가 쿼리를 깊게 중첩하거나 한 번의 호출로 거대한 목록을 요청할 수 있습니다. 여러 계층으로 방어합니다 — **depth 제한, complexity/cost 분석, rate limiting, 그리고 올바른 인증** — 이들 중 어느 것도 쿼리 언어가 대신 강제해 주지 않습니다.

## 위협: 제한 없는 쿼리

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

## 방어

- **Depth 제한** — 예컨대 7단계를 넘게 중첩된 쿼리를 거부합니다. 값싼 1차 방어선입니다.
- **Cost/complexity 분석** — 각 필드에 비용을 부여하고, 리스트 필드는 `first` 인자로 가중치를 주며, 총합이 예산을 초과하면 실행 전에 거부합니다. 리스트 폭을 고려하므로 단순 depth보다 강력합니다.
- **Rate limiting** — 클라이언트별 예산으로, 이상적으로는 (요청 수만이 아니라) **query cost** 기준으로 하여 비싼 쿼리 하나가 여러 개로 계산되게 합니다.
- **Persisted/허용 목록 쿼리** — 프로덕션에서는 미리 등록된 쿼리 집합만 받습니다; 임의의 즉석 쿼리는 거부되어 대부분의 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
  ],
});
```

## 인증

한 번 인증하고(`context`에서 토큰을 검증), 그다음 **필드/resolver 단위로 인가**하세요 — 클라이언트가 필드를 생략해 줄 것이라고 절대 믿지 마세요. resolver나 GraphQL Shield 같은 계층에서 확인하고, 프로덕션에서는 **introspection schema를 절대 노출하지 말고** 장황한 스택 트레이스도 노출하지 마세요.

## 왜 중요한가

REST endpoint는 본질적으로 경계가 있지만, 단일 GraphQL 쿼리는 그렇지 않습니다. senior 면접관은 **cost 기반** 사고방식 — depth는 필요하지만 불충분하고, complexity 분석에 persisted query를 더한 것이 진짜 답 — 과 resolver별 인가의 규율을 원합니다.

위협: 제한 없는 쿼리

방어

인증

왜 중요한가

관련 질문