คุณป้องกัน GraphQL API จาก query ที่เป็นการโจมตีอย่างไร?

Question

IT Interview Practice · Accepted Answer

ความยืดหยุ่นที่ทำให้ GraphQL ทรงพลังก็ทำให้มันเป็น **พื้นผิวการโจมตีแบบ DoS** ด้วย: client สามารถซ้อน query ให้ลึกมาก หรือขอ list ขนาดมหึมาในการเรียกครั้งเดียวได้ คุณต้องป้องกันเป็นชั้น ๆ — **จำกัดความลึก, วิเคราะห์ complexity/cost, rate limiting และ auth ที่ถูกต้อง** — ซึ่งไม่มีข้อใดที่ตัวภาษา query บังคับใช้ให้คุณ

## ภัยคุกคาม: query ที่ไม่มีขอบเขต

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

## แนวทางป้องกัน

- **การจำกัดความลึก (Depth limiting)** — ปฏิเสธ query ที่ซ้อนลึกเกิน เช่น 7 ระดับ เป็นแนวป้องกันด่านแรกที่ต้นทุนต่ำ
- **การวิเคราะห์ cost/complexity** — กำหนด cost ให้แต่ละ field ถ่วงน้ำหนัก list field ตามอาร์กิวเมนต์ `first` ของมัน และปฏิเสธก่อน execute หากผลรวมเกินงบที่กำหนด แข็งแกร่งกว่าการวัดความลึกล้วน ๆ เพราะคำนึงถึงความกว้างของ list ด้วย
- **Rate limiting** — งบต่อ client โดยควรอิงกับ **cost ของ query** (ไม่ใช่แค่จำนวน request) เพื่อให้ query ที่แพงหนึ่งครั้งนับเท่ากับหลายครั้ง
- **Persisted/allow-listed query** — ใน production ให้รับเฉพาะชุด query ที่ลงทะเบียนไว้ล่วงหน้าเท่านั้น query เฉพาะกิจตามอำเภอใจจะถูกปฏิเสธ ซึ่งกำจัดช่องทางการโจมตีแบบ 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
  ],
});
```

## Auth

ทำ authentication ครั้งเดียว (ตรวจสอบ token ใน `context`) จากนั้น **ทำ authorization ต่อ field/resolver** — อย่าไว้ใจให้ client เป็นผู้ตัด field ออกเอง ทำการตรวจสอบใน resolver หรือในชั้นอย่าง GraphQL Shield และ **อย่าเปิดเผย introspection schema** หรือ stack trace แบบละเอียดใน production เด็ดขาด

## ทำไมจึงสำคัญ

endpoint ของ REST มีขอบเขตตามธรรมชาติ แต่ query เดียวของ GraphQL ไม่มี ผู้สัมภาษณ์ระดับ senior ต้องการแนวคิดแบบ **อิงต้นทุน (cost-based)** — ความลึกจำเป็นแต่ไม่เพียงพอ การวิเคราะห์ complexity ร่วมกับ persisted query คือคำตอบที่แท้จริง — และวินัยของการทำ authorization ต่อ resolver

ภัยคุกคาม: query ที่ไม่มีขอบเขต

แนวทางป้องกัน

Auth

ทำไมจึงสำคัญ

คำถามที่เกี่ยวข้อง