GraphQLを安全に使うためにやっていること

「テックリードの悩みを解決するGraphQLの話」にて弊社エンジニア重本が登壇した資料です。
https://estie.connpass.com/event/328999/

Transcript

1. GraphQLを安全に使うためにやっていること 株式会社PICK 重本 太宏
2. 重本 太宏 / Takahiro Shigemoto 自己紹介 Web Engineer at PICK BE : FE = 7 : 3 設計が好き お気に入りはオニオンアーキ × DDD × テスト駆動
3. GraphQLの利点 利便性がもたらすリスク 01. PICKで行っている対策 02. 03. 目次 まとめ 04.
4. 01. GraphQLの利点
5. GraphQLの利点 01. GraphQLの利点 • いちいちエンドポイントを考える必要がない。増えない。 • 型でFEとBEが語り合える • FEでレスポンスを型安全に扱うことができる • 一つのクエリで様々なデータフェッチに対応することができる • オーバーフェッチを考慮しなくていいので、 API実装側はYAGNIをあまり気 にせず実装可能
6. GraphQLの柔軟性の理由 01. GraphQLの利点 A. GraphQLは「型というノードがグラフで繋がれた世界にアクセスするためのク エリ言語」 だから • SQLに近い • リレーションさえしていれば（エッジで繋がってさえいれば）縦横無尽にフィール ドを取得することができる
7. 01. GraphQLの柔軟性の理由 GraphQLの利点 Compa ny Team Contrac t User
8. 02. 利便性がもたらすリスク
9. 利便性がもたらすリスク 02. 利便性がもたらすリスク • どこからでも引っ張ってこれることによる、意図しないフィールド露出 • 複雑なクエリや深いクエリを呼ばれることによる DoS攻撃リスク 取ろうと思えばフィールドを取れすぎるのが元凶
10. 03. PICKで行っている対策
11. フィールド露出対策 03. PICKで行っている対策 • 敢えて有向グラフにする • フィールドに認可機能を入れる
12. フィールド露出対策 03. PICKで行っている対策 あえて有向グラフにする • 有向にすることで意図しないフィールド露出を抑制できる • メリット • 簡単にできる • デメリット • 利便性が下がる • 把握が難しい Compa ny Team Contrac t User
13. フィールド露出対策 03. PICKで行っている対策 フィールドに認可機能を入れる • NestJSが提供している FieldMiddlewareを利用 • フィールドを解決する前後に処理を追加してくれる機能を利用する • PICKではResolver関数の認可を Guardで行い、フィールドの認可を FieldMiddlewareで行って いる
14. フィールド露出対策 03. PICKで行っている対策 フィールドに認可機能を入れる 1. Resolverの引数に入る Contextに必要な情報を入れる 2. FieldMiddlewareを定義する 3. フィールドに適用する
15. フィールド露出対策 03. PICKで行っている対策
16. DoS攻撃対策 03. PICKで行っている対策 • 同時にいくつものクエリを叩ける • 深く取得しようと思えばいくらでもいける GraphQLはQueryによってサーバーに過剰なストレスを与えることができる
17. DoS攻撃対策 03. PICKで行っている対策 • Apollo-serverのvalidationRulesオプションを利用し、同時に叩ける Query数を制 限 • GraphQL Depth Limitを導入し、深さを制限 ならばクエリの数と深さを制限すればいいじゃない
18. Dos攻撃対策 03. PICKで行っている対策 同時に叩けるクエリ数を制限 graphql-jsパッケージに含まれる validationContextクラ スを使用。 （Queryがパースされた ASTが入っている）
19. Dos攻撃対策 03. PICKで行っている対策 深さを制限 GraphQL Depth Limitを導入
20. 04. まとめ
21. まとめ 04. まとめ • GraphQLはフィールドを縦横無尽に取得できて超便利 • 型がグラフでつながり合った世界にアクセスする仕組みだから • その利便性ゆえに起こる問題 • どこからでも引っ張ってこれることによる、意図しないフィールド露出 • あえて有向グラフにする • resolver関数だけでなくフィールドにも認可を機能をつける • 複雑なクエリや深いクエリを呼ばれることによる DoS攻撃リスク • 同時に叩ける Query数を制限する • 深さを制限する この2つはかなり手軽に導入できるのでおすすめ
22. 今後の課題 04. まとめ • クエリの複雑度分析を取り入れていきたい • IntrospectionやAlias等をOFFにすることの検討 • CQRSとか考慮したい
23. ご清聴ありがとうございました