HTTP 400 Bad Request：意味と解決方法

このエラーの意味と見分け方

• ブラウザー、APIクライアント、稼働監視、Webhook送信元などのHTTPクライアントが400 Bad Requestを報告する。
• 特定のURL、HTTPメソッド、クエリ文字列、リクエストボディ、ヘッダーセット、またはクライアントでのみレスポンスが発生する場合がある。
• エンドポイントがHTTPレスポンスを返しているため、DNSが解決し、TLSが完了することがある。
• レスポンスボディには、レスポンスを生成したコンポーネントに応じて、一般的なエラーページまたはより具体的な検証メッセージが表示される場合がある。
• レスポンスヘッダーから、キャッシュの状態、プロキシやCDNの情報、認証コンテキスト、リダイレクト、リクエストIDが分かる場合がある。
• 以前は動作していたリクエストが、デプロイやルーティング、検証、プロキシ、セキュリティルールの変更後に400を返し始めることがある。

可能性の高い順の主な原因

1. 不正または無効なリクエストの詳細： URL、クエリ文字列、ヘッダー、Cookie、メソッド、リクエストボディが、エンドポイントの想定する形式を満たしていない可能性があります。
2. アプリケーションの検証またはルーティングルール： 必須パラメーターの欠落、型の誤り、未対応の値、不整合なパラメーターをアプリケーションが拒否している可能性があります。また、そのメソッドを受け付けないルートにリクエストしている場合もあります。
3. Webサーバー、リバースプロキシ、CDN、WAFによる処理： パース、ルーティング、フィルタリング、ポリシールールにより、アプリケーションに到達する前に中継コンポーネントがリクエストを拒否することがあります。
4. リクエストサイズまたは形式の制限： ボディ、ヘッダーセット、URL、Cookieの集合、アップロード値が環境固有の上限を超えているか、未対応の形式を使用している可能性があります。
5. 認証またはセッションに関連するリクエスト状態： 無効なトークン、壊れたセッションデータ、または想定される状態と関連付けられないリクエストに対して、アプリケーションが400を返すことがあります。関連するアクセス問題に対して401または403を使用するシステムもあるため、該当するログで動作を確認してください。
6. 最近の設定またはデプロイの変更： ルート、検証ロジック、認証、キャッシュ、プロキシ、CDN、セキュリティ設定の更新により、これまでと同じように見えるリクエストの処理方法が変わることがあります。

修正方法

訪問者またはAPI利用者の場合

1. 正確なURLを一度再試行し、入力ミス、意図しないスペース、途中で切れたクエリパラメーター、古いブックマークがないか確認します。
2. アカウントが必要なリクエストの場合は、サイトの通常の手順でサインインしてから再試行します。パスワード、Cookie、トークンをサポートへの問い合わせに貼り付けないでください。
3. APIクライアントを使用している場合は、HTTPメソッド、必須パラメーター、ヘッダー、コンテンツタイプ、リクエストボディを、エンドポイントのドキュメントに記載された要件と比較します。
4. ブラウザーからのリクエストが失敗する場合は、何度も更新せずに同じ操作を試します。リクエストを繰り返すと負荷が増えたり、レート制限に影響したりすることがあります。
5. URLまたはエンドポイント、メソッド、おおよその時刻、レスポンスステータス、レスポンスに表示されたリクエストIDを記録します。サイト所有者に共有する詳細は、機密情報を除いたものだけにしてください。
6. 1つの操作だけにエラーが発生する場合は、その操作と期待する動作を報告します。関係のない複数のページで失敗する場合は、すべての失敗が同じ原因だと考えず、影響範囲全体を報告します。

サイトを所有または開発している場合

1. 最小限の再現手順を記録します。 HTTPメソッド、機密情報を削除した完全なURL、ステータス、レスポンスヘッダー、関連するリクエストヘッダー、コンテンツタイプ、安全に最小化したリクエストボディを記録します。400が、リダイレクトに続く中間レスポンスではなく最終レスポンスであることを確認します。
2. 成功するリクエストと失敗するリクエストを比較します。 ルート、メソッド、クエリパラメーター、ボディ形式、コンテンツタイプ、Cookie、認証状態、クライアント、ペイロードサイズを確認します。関連する変数は一度に1つだけ変更します。
3. レスポンスを返した層を特定します。 レスポンスヘッダー、ボディの文言、リクエストID、タイムスタンプから、アプリケーション、Webサーバー、リバースプロキシ、CDN、WAFのどれがレスポンスを生成したかを判断します。ヘッダー名と値は環境によって異なるため、確証ではなく手がかりとして扱ってください。
4. 対応するログを調べます。 特定した層と、その周辺コンポーネントを、同じ時刻、ルート、メソッド、リクエスト識別子で検索します。パーサーエラー、検証失敗、拒否されたメソッド、制限超過、ルーティングの不一致、セキュリティルールへの一致を確認します。
5. 最近の変更を確認します。 ルーティング、リクエストのパース、認証、キャッシュ、プロキシ転送、CDNの動作、WAFルールに影響するデプロイや設定変更を比較します。失敗しているリクエストが、そのルートで受け付けられる想定か確認します。
6. 安全性を保った最小限の修正を行います。 リクエストの仕様、または正当なトラフィックを拒否している特定のルートやルールを修正します。権限とテストなしに、セキュリティ、権限、サイズ制限、プロキシの設定を広範囲に変更することは避けてください。
7. 再テストし、周辺の動作を確認します。 元のリクエストを再実行し、想定するメソッド、代表的な不正リクエスト、関連するルートをテストします。修正によって不正なリクエストが意図せず成功したり、リダイレクト、認証、キャッシュ、セキュリティ制御が壊れたりしないことを確認します。
8. 有用な証拠を保持します。 通常の保存期間とプライバシー対策に従い、機密情報を除いたリクエストの詳細、タイムスタンプ、関連ヘッダー、ログを保管します。

予防と修正確認

• 重要なルートについて、受け付けるメソッド、パラメーター、コンテンツタイプ、認証要件、リクエストサイズの上限を定義し、文書化します。
• リクエストを一貫した方法で検証し、適切な場合には有用で機密情報を含まないエラーメッセージを返します。
• ルーティング、プロキシ、CDN、認証、キャッシュ、WAFの設定を変更管理の対象にします。
• アプリケーションまたはインフラストラクチャをリリースした後、代表的な正常系と異常系のリクエストをテストします。
• ルート、メソッド、クライアント、デプロイごとに400の発生率を監視し、局所的なリグレッションと広範な変更を区別できるようにします。
• レスポンスと、それを生成したコンポーネントを関連付けられるよう、リクエストIDと関連ログを十分な期間保持します。
• ログとサポート用の証跡から、パスワード、Cookie、認証情報、個人データ、APIシークレットをマスキングまたは削除します。

よくある質問