リソース · 37
GraphQL APIのセキュリティ確保：認可、クエリコスト、および証拠
オブジェクトとフィールドの権限を強制し、サーバー側の処理をバインドし、拒否パスをテストする。
更新済み · 3 min
このガイドが達成するのに役立つこと
- 公開スキーマのマッピング
- 権限の行使
- バインドクエリのコスト
- 拒否の検証
クイックチェック
- あるアカウントが別のアカウントのオブジェクトを読み取ることができるか？
- 機密フィールドは親のアクセス決定に従うか？
- 深度、エイリアス、ページネーションのコストは合計でどのくらいか？
- エラーによって漏洩する詳細情報は何か？
- 拒否と不正使用を監視するのは誰か？
手順
- 1
操作のインベントリ
型、フィールド、ミューテーション、ロール、オブジェクト所有者、機密データを一覧表示する。 現在のクライアントクエリと使用頻度の低いパスを含める。
成果物：操作、ロール、オブジェクト、フィールドのマトリックス
- 2
各アクセス決定をテストする
個別のテストアカウントを作成し、ネストされたオブジェクトを含むオブジェクトIDを交換する。 リゾルバはデータを返す前に認証を適用する必要がある。
成果物：再現可能な許可および拒否ケース。
- 3
バインドされたサーバー作業
フィールドとコレクションの実際のコストを測定する。 深さ、幅、エイリアス、ページネーション、バッチ処理、および時間を同時にテストし、適切な制限を設定する。
成果物：コストポリシーと敵対的クエリセット。
- 4
不要な露出の削減
コンテキストに対するイントロスペクションを決定し、内部エラーの詳細を非表示にし、クライアントが必要とする以上の情報を明らかにするフィールドを削除する。
成果物：レビュー済みの公開構成とエラー応答。
- 5
抑制された監視
機密情報と機密性の高い引数を除外し、有用な技術的ID、操作、コスト、拒否、および相関関係をログに記録する。 アラートの所有者を割り当てる。
成果物：ダッシュボードと調査手順。
- 6
変更後のリプレイ
フィールド、ロール、またはクライアントが変更された場合、承認を再実行し、ケースをロードする。 改訂後のグラフをたどる古いクエリを確認してください。
成果物：回帰テスト結果とリリース決定
管理指標
| 指標 | 測定対象 | 最初のアクション |
|---|---|---|
| アクセス | オブジェクトとフィールドのケースが想定どおりに拒否される | リゾルバを修正 |
| コスト | 重いクエリはポリシーによって制限される | フィールドと制限を調整 |
| エラー | 内部詳細を含まない公開レスポンス | 公開される詳細情報を削減 |
| 回帰分析 | 変更後にクライアント操作がリプレイされる | 意図しない破損を防ぐ |
よくある間違い
- エンドポイントアクセスのみを信頼する
- 深さを制限するが幅を無視する
- ネストされたフィールドの認証を忘れる
- 機密データを含む引数をログに記録する
よくある質問
GraphQLは通常のAPI認証を不要にする？
いいえ。すべてのオブジェクトとフィールドへのアクセスには、IDとコンテキストに基づく判断が必要です。
イントロスペクションを無効にするだけで十分か？
いいえ。スキーマの露出を減らすことはできますが、アクセスやクエリのコストは解決しません。
深さ制限だけで十分か？
いいえ。エイリアス、幅、リスト、フィールド固有のコストも重要です。
公式参照文献
参照文献はメソッドを裏付けるものです。 チェックは状況に合わせて調整してください。 これらは認証ではありません。 元の参照文献のタイトルやソース文書は別の言語で書かれている場合があります。
