RESTトラフィックでは、エンドポイント、メソッド、パスが通常リクエストの内容を説明します。GraphQLでは、その情報はほとんどボディにあります。同じ`/graphql`エンドポイントが読み取り、書き込み、ネストクエリ、イントロスペクション、フラグメント、変数を使ったオペレーションを運ぶことができます。URLとメソッドレベルのみをチェックするセキュリティ層はGraphQLが実際に何をしているかを見ることができません。
GraphQLイントロスペクションが本番環境で開いたままであれば、アプリケーションスキーマが漏洩する可能性があります。どのタイプ、フィールド、関係が存在するかを知った攻撃者はより標的を絞ったクエリを作成できます。これは直接的なデータ漏洩ではないかもしれませんが、攻撃面をマップする深刻な情報開示です。
ネストクエリとフラグメントは異なるリスクを生み出します。過度にネストされたクエリは単一のHTTPリクエストでバックエンドに重い処理負荷を課すことができます。標準的なレート制限はリクエストを数えます — 単一リクエストのコストは見えません。GraphQLでは、DoSリスクは通常リクエスト量ではなくクエリ構造から来ます。
クエリバッチングも同様のギャップを生み出します。複数のクエリが1つのボディで送信されると、外部からは単一のHTTPリクエストのように見えますが、内部で複数のオペレーションが実行される可能性があります。これはクラシックなレート制限とエンドポイントベースのセキュリティコントロールを弱めます。
TR7 GraphQL Deep InspectionはパターンベースのWAAPルールでGraphQLトラフィックを検査します：イントロスペクション、ネスト深度DoS、クエリバッチング動作がquery、raw、json、formスコープで検出され、本番ポリシーに結び付けられます。
TR7はGraphQLセキュリティをスキーマ認識を主張するのではなく、最も一般的な本番GraphQL悪用パターンをWAAPシグネチャエンジンに取り込むことで対処します。
TR7は`__schema`、`__type`、`IntrospectionQuery`、`fragment FullType`などのイントロスペクション指標をregexベースのルールで検出します。これらのルールは本番環境でブロックモード、ステージング環境ではモニターモードまたは低いスコアで実行できます。
過度にネストされたGraphQLクエリは単一リクエストで重い処理負荷を生成できます。TR7の50101ルールファミリーはパターンレベルで深い`{ ... { ... } }`チェーンを検出し、高いスコアでWAAP決定に含めます。
1つのボディで複数のクエリを送信することはクラシックなレート制限ロジックを弱める可能性があります。TR7ルール50102はバッチクエリパターンを検出し、その動作をログ、スコア、ブロック決定に結び付けることを可能にします。
GraphQLクエリはrawボディだけでなく、JSON、フォーム、クエリ文字列フィールドでも運ばれる可能性があります。TR7ルールはquery、raw、json、formスコープで動作し、異なるクライアント実装を同じWAAPポリシー下に取り込みます。
GraphQL Deep InspectionはシグネチャベースのWAAPルール、スコープ選択、エンドポイント強化コントロールでGraphQL固有のリスクを管理します。
ルール50100はGraphQLイントロスペクションでよく使われる`__schema`、`__type`、`IntrospectionQuery`、`fragment FullType`パターンを対象とします。デフォルトのリスクレベルは中程度の強さのシグナルとして位置付けられ、スコア4で評価できます。本番環境でイントロスペクションを閉じる必要があるエンドポイントでは、このルールをブロックまたはモニターモードで実行できます。スキーマ発見の試みがWAAPイベントストリームで可視化されます。
ルール50101はパターンレベルで過度にネストされたGraphQLクエリを検出するために使用されます。深い`{`チェーンと重くネストされた構造は単一リクエストがバックエンドで高い処理コストを生み出す原因となる可能性があります。このルールはスコア6でより強い攻撃シグナルとして評価できます。目標はスキーマを認識した複雑性の計算を行うことではなく、危険なネストクエリパターンを早期に検出することです。
ルール50102は単一ボディで複数のクエリが送信されるバッチパターンを検出します。クエリバッチングは一部のクライアントにとって正当である可能性があるため、ルールの状態とスコア値はアプリケーションの動作に合わせて調整する必要があります。モニターモードで開始し実際のトラフィック観察で明確にすることが適切なアプローチです。悪用が確認されたら、ルールをブロッキングポリシーに移行できます。
TR7エンリッチドルールに加えて、waf_dbには50100、50101、21360+ファミリーなどのGraphQLバリアントが含まれています。これらのバリアントは`__schema {`、`__type`、`__typename`、ネストmutationパターンなどの代替スペリングをカバーします。これにより単一のregexに依存することなく、イントロスペクションとネストクエリ動作のより広いシグネチャ表面が構築されます。オペレーターはこれらのルールの状態とスコア値をサービスごとにオーバーライドできます。
GraphQLクエリは常に同じ形式で届くとは限りません。一部のクライアントはJSONボディ内に`query`、`variables`、`operationName`フィールドを送信し、他のクライアントはrawボディまたはフォームフィールドを使用することがあります。TR7ルールはquery、raw、json、formスコープで動作し、これらの異なるトランスポート形式を検査のカバレッジに取り込みます。これはGraphQLエンドポイントで1つのボディ形式のみを信頼する誤りを減らします。
GraphQLコントロールはapi_endpointとweb_applicationの両方のターゲットに適用できます。同じWAAPルールモデルは、サービスタイプに応じて異なる状態、スコア、スコープ値で管理できます。例えば、内部テストエンドポイントではイントロスペクションがモニターモードに留まりながら、公開本番エンドポイントではブロックできます。この柔軟性により、単一のルールセットを異なる環境ポリシーに適応させることができます。
`/graphql`エンドポイントに対してPOSTメソッドのみを許可したり、期待されるJSONキーを`query`、`variables`、`operationName`に制限したり、ボディサイズ制限を適用するなどのコントロールを定義できます。これらのコントロールはGraphQLシグネチャの代替ではなく、それらを補完するポジティブセキュリティ層です。予期しないメソッドや予期しないJSONフィールドは早期段階で拒否できます。これによりエンドポイントの動作がより予測可能になります。
GraphQLトラフィックにアプリケーション固有のmutationパターン、フィールド名、リスクのあるオペレーション名が含まれる場合は、カスタムWAAPルールとして追加できます。例えば、ボディに特定の`mutation`キーワードや機密オペレーション名が現れたときに高いスコアを付けることができます。これらのカスタムルールはメインのWAAPスコアリングシステムに参加し、ログとSIEMストリームで可視化されます。スキーマを認識したフィールド検査なしでも、アプリケーション固有のリスクをパターンベースのルールで検出できます。
GraphQL Deep Inspectionは現在の実際の機能においてシグネチャベースです — オペレーションパース、複雑性計算、スキーマを認識したフィールドWAAPの主張はこのページの範囲外です。
GraphQLコントロールはregexとスコープベースのパターン検出アプローチで動作します。オペレーションタイプの区別、実際の深さカウンター、クエリ複雑性スコア計算はこのモデルの一部ではありません。この区別は正確な位置付けのために特に重要です。
ルール50100、50101、50102、およびwaf_dbバリアントはサービスのニーズに応じてenabled、monitor、disabledに設定できます。スコア値もアプリケーションの偽陽性許容度に合わせて調整できます。本番GraphQLエンドポイントでの適切なロールアウトモデルはモニターモードで開始し、実際のトラフィック観察後にブロッキングに移行することです。
GraphQLエンドポイントにメソッドallow-list、JSONキーallow-list、ボディサイズ制限を適用できます。これらのコントロールはシグネチャ検出と並んでリクエスト形状が期待されるコントラクトに準拠することを確認します。特に公開APIでは、`/graphql`エンドポイントで期待される形式のみを受け入れることで攻撃面が絞り込まれます。
オペレーションごとのレート制限はGraphQLパーサーレベルでは適用されません。単一ボディ内のオペレーション数を意味的にパースして各オペレーションに別々の制限を適用するという主張はありません。クエリバッチングパターンはシグネチャとして検出でき、一般的なレート制限ポリシーと組み合わせて使用できます。
パーシステドクエリに対する専用サポートはこの機能の範囲内には含まれません。リクエストで見えるGraphQLパターンはWAAPシグネチャで検査されます。ハッシュからクエリを解決してスキーマまたは登録されたオペレーションデータと照合することはこのページでは主張されません。
特定のGraphQLスキーマフィールド — 例えば`User.email` — のレベルでのネイティブ検査は実行されません。ルールはボディに対するパターンマッチングアプローチで動作します。フィールド固有の要件がある場合は、カスタムregexルールで限定的かつ慎重に対処する必要があります。
セキュリティチームはステージングでイントロスペクションを許可しながら、本番エンドポイントではルール50100をブロックモードで実行できます。スキーマ発見の試みはポリシーに従ってログ、スコアリング、ブロックされます。
過度にネストされたフラグメントまたはクエリ構造はバックエンドで高い処理コストを課す可能性があります。ルール50101はスコア6でこれらのパターンを検出し、WAAPブロッキング決定に強いシグナルを提供します。
モバイルクライアントエンドポイントへの単一リクエストで多数のクエリが試みられると、ルール50102がバッチパターンを検出します。運用チームは最初にモニターモードで動作を確認し、悪用が確認されたらenableモードに切り替えることができます。
APIチームは`/graphql`エンドポイントでPOSTメソッドと`query`、`variables`、`operationName`JSONフィールドのみを許可できます。予期しないメソッドやフィールドはアプリケーションに到達する前に拒否され、エンドポイントの動作が絞り込まれます。
イントロスペクション、ネストDoS、クエリバッチングリスクを本番環境で可視化して管理可能にします。お客様自身のサービスでのライブセットアップを一緒に確認しましょう。