結論（HTTP応答・エラーページ）
HTTP応答・エラーページの診断では、トップページが2xxで正常に応答するか、存在しないURLに404または410を返すか、エラー画面にスタックトレースや内部パスが出ないか、エラー応答にも防御ヘッダーが付くか、OPTIONSが不要なメソッドを示さないか、外部URLへのオープンリダイレクトがないかを確かめます。最優先は重要（high）の3項目です。
HTTP応答・エラー処理の診断項目一覧（6項目）
応答ステータス、エラーページのデバッグ情報、HTTPメソッド、オープンリダイレクトを確認します。各項目名から、意味・診断基準・リスク・具体的な対策を解説したページへ移動できます。
| No. | 診断項目 | 重大度 | 概要 |
|---|---|---|---|
| 33 | トップページが正常応答 | high | トップページが正常応答しているかは、転送後の最終応答がHTTP 2xxかで判断します。 |
| 76 | 存在しないURLのステータス | medium | 存在しないURLのステータスは404（Not Found）か410（Gone）が正解です。 |
| 77 | エラー応答のデバッグ情報 | high | エラー応答のデバッグ情報とは、エラー画面に出るPHP警告・スタックトレース・内部パス・SQLエラーなどの開発向け詳細です。 |
| 78 | エラー応答のヘッダー整合性 | medium | エラー応答のヘッダー整合性とは、404・403・500などのエラー応答にもnosniffやCSPを付け、正常応答とキャッシュ方針をそろえることです。 |
| 124 | OPTIONSが示す不要・危険なHTTPメソッド | medium | OPTIONSが示す不要・危険なHTTPメソッドを解説。 |
| 126 | 外部URLパラメータへのオープンリダイレクト | high | 外部URLパラメータへのオープンリダイレクトを解説。 |
HTTP応答・エラーページの診断とは
HTTP応答・エラーページの診断は、Webサーバーが返す「応答そのもの」が正しく、安全に作られているかを確かめるものです。セキュリティ診断127項目のうち、HTTPステータスコード、エラー時の表示とヘッダー、HTTPメソッド、リダイレクトに関する6項目がこの分類に入ります。
ふだん利用者が見るのは正常なページですが、攻撃者はむしろ異常系に注目します。存在しないURLにアクセスしたときに何が返るか、エラー画面に開発時の詳細情報が出ないか、受け付けるHTTPメソッドに不要なものがないか、遷移先を指定するパラメータに外部のURLを入れたらどうなるか、といった点です。正常なページだけを整えても、エラーページやリダイレクトの処理に穴があれば、そこが情報漏えいや攻撃の入口になります。
また、この分類にはトップページが正常に応答しているかという、診断全体の前提になる項目も含まれます。トップページがエラーを返していると、ヘッダーやCookieなど他の診断結果もエラーページに対する判定になってしまうため、最初に確認すべき土台でもあります。
6項目の全体像（3つのグループ）
この分類の6項目は、何を確認するかによって3つのグループに分けて考えると整理しやすくなります。
| グループ | 診断項目 | 確認する内容 |
|---|---|---|
| ステータスコード | 「トップページが正常応答」、「存在しないURLのステータス」 | トップページがリダイレクト後に2xxを返すか、存在しないURLに404または410を返すか（200やトップページへの転送はソフト404） |
| エラー応答の中身 | 「エラー応答のデバッグ情報」、「エラー応答のヘッダー整合性」 | エラー画面にPHPエラー・内部パス・SQLエラー・スタックが出ないか、エラー応答にもnosniffやCSPが付き、no-storeの方針が正常応答とそろっているか |
| メソッドと転送 | 「OPTIONSが示す不要・危険なHTTPメソッド」、「外部URLパラメータへのオープンリダイレクト」 | OPTIONSの応答にTRACE・PUT・DELETE・WebDAV系のメソッドが並ばないか、?url= や ?next= に外部URLを入れたときに外部へ転送しないか |
「存在しないURLのステータス」「エラー応答のデバッグ情報」「エラー応答のヘッダー整合性」の3項目は、同じ存在しないURLへの1回のGETの応答を使って判定します。能動的に500エラーを起こすような不正入力は送らない、受動的な確認です。
優先して確認すべき項目
この分類には最重要（critical）の項目はありませんが、「重要（high）」の3項目を最初に確認します。
- トップページが正常応答：リダイレクトをたどった最終応答が2xxでなければ×です。住民への情報提供が止まっているだけでなく、サーバー設定ミスやCMSの例外、WAFの過剰なブロックなどが背後にある可能性があります。なお、最終応答が403や429の場合は診断用アクセスが拒否されたものとして、診断全体がエラーになります。
- エラー応答のデバッグ情報：存在しないURLの応答に、PHPエラー、内部パス、SQLエラー、JavaScriptのスタック、フレームワークの詳細エラーのいずれかが出ていれば×です。使用言語やバージョン、サーバー上のパスが分かり、SQLエラーはエラーベースのSQLインジェクションの足掛かりにもなります。
- 外部URLパラメータへのオープンリダイレクト：遷移先を表すパラメータに外部URLを入れると、そのサイトへ転送してしまう脆弱性（CWE-601）です。信頼された正規のドメインを入口にして偽サイトへ誘導でき、フィッシングに直結します。meta refreshによる自動遷移も×になります。
次に「中（medium）」の3項目として、ソフト404、エラー応答のヘッダー整合性、OPTIONSが示すメソッドを確認します。これらは×を使わず△で示す項目で、直接の侵害ではなく、運用・検知性の問題や多層防御の穴を示すものです。
直すときの進め方と注意点
応答やエラー処理の設定は、サーバー・CMS・アプリケーションのどこで応答が作られているかによって直す場所が変わります。次の点に注意して進めます。
- トップページのエラーは原因を切り分ける：ブラウザでは表示できるのに診断がエラーになる場合は、WAFやCDNがブラウザらしくないUser-Agentや海外のIPアドレスを拒否している可能性があります。意図した制限かを確認します。計画メンテナンスでは200ではなく503とRetry-Afterを返し、期間を決めて終了させます。
- 404ページは「見た目」ではなくステータスを確かめる：カスタム404ページを作っても、設定によってはステータスが200になっていることがあります。たとえばApacheで ErrorDocument に完全なURLを指定すると、クライアントへのリダイレクトになりソフト404になります。curlなどでステータスコードを確認します。
- デバッグ表示は止め、ログに記録する：PHPでは display_errors と display_startup_errors を Off、log_errors を On にします。LiteSpeed・CGI・FPM環境では .user.ini、mod_php なら php.ini で設定します。.htaccess の php_flag は mod_php 以外では500エラーの原因になるため使いません。
- ヘッダーはエラー応答にも付ける：Apacheでは Header always set、nginxでは add_header に always を付けます。nginxでは下位の階層に add_header が1つでもあると上位の指定が継承されない点にも注意します。
- 不要なメソッドを止め、OPTIONS自体は止めない：ApacheのTRACEは Limit や LimitExcept では制限できないため、httpd.conf で TraceEnable Off にします。OPTIONSはCORSのプリフライトで使われるため、止めるべきはOPTIONSではなく不要なメソッドそのものです。
- 遷移先はパラメータで受け取らない：オープンリダイレクトの恒久対策はアプリ側の修正です。遷移先をパラメータで受け取らないか、自サイト内の相対パスまたは完全一致の許可リストで検証します。Webサーバーで外部URLを含むパラメータを拒否する方法は、回避パターンを網羅できないため暫定対処にとどめます。
自治体・公共機関のサイトで特に注意すること
自治体や公共機関のサイトは、住民からの信頼が高い分、異常系の不備が悪用されたときの影響も大きくなります。よくある例として、次のようなものがあります。
- 外部リンクのクリック計測用の /cgi-bin/jump.cgi?url=... が、渡されたURLへそのまま転送する。正規ドメインのURLを入口にした、給付金や税の還付を装うフィッシングに悪用されるおそれがあります。
- 404ページが共通部品を読み込む際にPHPの警告を出し、/home/アカウント名/public_html/ のようなサーバー上のパスが表示される。
- .htaccess に always なしの Header set で nosniff を書いており、ErrorDocument の静的な404ページにはヘッダーが付いていない。
- Apacheの既定設定のまま、OPTIONSの応答に TRACE が並んでいる。WebDAVを有効にしたファイル共有領域と同じサーバーでは、PUTやDELETEなども並ぶことがあります。
- CMSの「ページが見つかりません」テンプレートを200で返しており、監視や診断が存在しないページを「存在する」と誤認する。
エラーページやリダイレクトの処理は、本体のCMSだけでなく、委託先が運用する予約・申請などのシステムにもあります。システムごとに、存在しないURLやエラー時の応答をcurlなどで確かめておくと、こうした不備を見つけやすくなります。
よくある質問（FAQ）
HTTP応答・エラーページの診断項目は、どの順番で直せばよいですか？
まず重要（high）の3項目、トップページの正常応答、エラー応答のデバッグ情報、外部URLパラメータへのオープンリダイレクトを確認します。次に中程度（medium）の、存在しないURLのステータス（ソフト404）、エラー応答のヘッダー整合性、OPTIONSが示す不要・危険なHTTPメソッドを整えます。
HTTP応答・エラーページの診断で、存在しないURLはどう確認していますか？
存在しないURLをGETで1回取得し、その最終ステータスでソフト404を、本文でデバッグ情報を、ヘッダーで防御ヘッダーの整合性を判定します。能動的に500エラーを起こす不正入力は送らない、受動的な確認です。
存在しないURLをトップページへリダイレクトするのは、エラーページの扱いとして問題ですか？
最終的に200になるためソフト404として扱われ、監視や検索エンジン、脆弱性診断、キャッシュが「存在する」と誤認する原因になります。404応答の本文に検索窓や主要リンクを置くのが適切です。
エラーページにもセキュリティヘッダーが必要ですか？
必要です。Apacheの Header set やnginxの add_header は既定ではエラー応答に付かないため、always を指定します。エラーページにも共通テンプレートのスクリプトや要求URLを表示する処理が含まれることが多く、nosniffやCSPがその被害を軽減します。
HTTP応答・エラーページの診断で○なら、オープンリダイレクトはないと言えますか？
言い切れません。○は「候補1件・値1種類で外部転送しなかった」という意味です。//形式などの回避パターン、JavaScriptでの転送、ログイン後のみ動く転送は検査していないため、リダイレクト機能を持つシステムでは手動確認が必要です。
HTTP応答・エラーページの6項目はまとめて確認できますか？
セキュリティAIチェッカーにURLを入力すると、この6項目を含む127項目を公開情報から自動で診断し、項目ごとの判定と改善の優先順位を表示します。