下層・エラー応答のバージョン／デバッグ情報とは？露出の確認方法・抑制設定・診断基準

下層・エラー応答のバージョン／デバッグ情報とは

下層・エラー応答のバージョン／デバッグ情報とは、トップページ以外の下層ページやエラー時の応答に含まれる、Webサーバーや実行環境のバージョン番号、CMSのバージョン、例外のスタックトレースやサーバー内部のファイルパスといった情報のことです。セキュリティAIチェッカーのこの項目は、トップページと下層ページの応答にこれらの情報が含まれていないかを確認します。

トップページだけを見る「サーバーバージョンを露出していない」や、存在しないURLの404応答を見る「エラー応答のデバッグ情報」を補完し、「下層に進むと別のアプリ・別のサーバーが応答していて、そこだけ情報が漏れている」状況を拾うための網羅性項目です。バージョン情報だけなら△（warn）、例外詳細などのデバッグ情報が出ていれば×（fail）とします。

何が「情報露出」になるのか

バージョン情報やデバッグ情報の露出はなぜ問題なのか

バージョン番号は「攻撃の下調べ」を楽にする

バージョン番号そのものは脆弱性ではありません。しかし攻撃者は版数から既知脆弱性（CVE）を絞り込めるため、情報を伏せることは「調査コストを上げる」多層防御の一部になります。OWASP ASVS 5.0.0でもバージョン非公開（V13.4.6）はLevel 3（高保証）の要件に位置付けられています。

デバッグ情報はより直接的に攻撃を助ける

一方、スタックトレースやSQLエラーの露出はより直接的です。ファイル配置、使用ライブラリ、データベースのテーブル名、SQL文の断片などが分かり、SQLインジェクション等の攻撃の成功確率を大きく上げます。

なぜ「下層」と「エラー応答」を見る必要があるのか

自治体サイトでは、CMS本体と、施設予約・電子申請・検索・地図などの別システムが同一ドメインの下層に同居していることが多く、それぞれ別のサーバー設定を持っています。トップページがCDN経由で整っていても、下層の別システムでは古い設定のままということが珍しくありません。

情報露出についてよくある誤解

• 「バージョンを隠せば安全」：隠蔽はパッチ適用の代わりになりません。攻撃ツールは版数を確認せずに既知の攻撃を試すことも多く、最優先は更新です。
• 「トップページで確認したから大丈夫」：上記のとおり、下層には別システム・別サーバーが同居していることがあります。
• 「エラー画面は利用者が見ないから問題ない」：攻撃者は意図的に不正な値を送ってエラーを起こします。エラー時の応答こそ確認が必要です。

下層・エラー応答のバージョン／デバッグ情報の診断基準（セキュリティAIチェッカー）

取得方法

1. トップページの応答（ヘッダー・本文）を使用します。
2. V2診断で集めた同一オリジンの巡回ページ候補のうち、トップページ以外の先頭2件をGETで追加取得します（1件あたり5秒・180KB上限、リダイレクト最大2回、別オリジンへ移動した応答は除外）。
3. 判定対象は最大3ページです。存在しないURLへの404応答は、本項目ではなく「エラー応答のデバッグ情報」で確認します。

露出兆候の判定ロジック

各ページについて、次のいずれかに該当すれば「露出兆候あり」と数えます。

判定条件

• Server: Apache や Server: nginx のように版数のない値はpassです。
• X-Powered-By は値に関係なく存在だけでwarnになります。フレームワーク名だけでも攻撃対象の絞り込みに使えるためです。
• 本文の文字列一致による判定のため、セキュリティ解説記事などで /var/www/ のような文字列を本文に掲載している場合は誤検知になり得ます。証拠欄の「該当ページ数/判定ページ数」を手がかりに、該当ページを目視で確認してください。
• CMSの生成ツール情報の単独確認は「生成ツール情報を露出していない」でも行います。

自治体サイトでの判定例

バージョン／デバッグ情報が露出しているとどんなリスクがあるか

• 既知脆弱性の効率的な探索：版数が分かると、攻撃者は該当するCVEとエクスプロイトを即座に選べます。サポート終了版（例：PHP 7系、CentOS 7同梱のApache）が見えると、優先的な標的になり得ます。
• SQLインジェクション等の成功率向上：SQLエラー文はデータベース製品、テーブル名、クエリ構造を示し、ブラインドでの試行を不要にします。
• 内部構成の把握：/var/www/html/ や C:\inetpub\wwwroot\ のようなパスは、OSやディレクトリ構成を示し、パストラバーサルやファイル読み出し攻撃の足がかりになります。
• 自治体特有の影響：委託先ごとに異なるシステムが同居するため、1つのシステムの露出から他システムの構成が推測されることもあります。

バージョン／デバッグ情報を隠す設定方法（Apache・nginx・IIS・PHP・Next.js・CMS）

Apache

# httpd.conf（ServerTokensは.htaccessでは設定不可）
# Server: Apache のみにする（既定はFull）
ServerTokens Prod
# エラーページ等のフッター署名を出さない（既定もOff）
ServerSignature Off

# X-Powered-By を除去（mod_headers）
<IfModule mod_headers.c>
  Header always unset X-Powered-By
  Header unset X-Powered-By
</IfModule>

Apacheの設定ファイルでは、ディレクティブと同じ行にコメントを書けません（構文エラーになります）。PHPの X-Powered-By は php.ini の expose_php = Off で根本的に止められます（expose_php は .user.ini では変更できません）。

共有ホスティングでhttpd.confを触れない場合は、.htaccess の Header unset X-Powered-By と、.user.ini での display_errors = Off が現実的な手段です（.htaccess の php_value はmod_php以外の環境で500エラーになるため使わないでください）。

nginx

http {
    server_tokens off;          # 既定は on（Serverヘッダーとエラーページに版数）
    fastcgi_hide_header X-Powered-By;
    proxy_hide_header   X-Powered-By;
}

IIS（web.config）

<configuration>
  <system.webServer>
    <security>
      <!-- IIS 10.0（Windows Server バージョン1709／2019以降）で有効。2016では効かない -->
      <requestFiltering removeServerHeader="true" />
    </security>
    <httpProtocol>
      <customHeaders>
        <remove name="X-Powered-By" />
      </customHeaders>
    </httpProtocol>
    <httpErrors errorMode="DetailedLocalOnly" />
  </system.webServer>
  <system.web>
    <customErrors mode="RemoteOnly" />
    <httpRuntime enableVersionHeader="false" />
    <compilation debug="false" />
  </system.web>
</configuration>

enableVersionHeader="false" は X-AspNet-Version を消します。customErrors と httpErrors で、外部からのアクセスには詳細エラーを出さないようにします。

PHP（php.ini / .user.ini）

; expose_php は php.ini のみ有効
expose_php = Off
display_errors = Off
log_errors = On
error_log = /var/log/php/error.log   ; 公開ディレクトリ外

Next.js（Vercel）

// next.config.js
module.exports = {
  poweredByHeader: false,   // 既定では X-Powered-By: Next.js を付与
};

本番ビルド（next build）では、例外のスタックトレースはブラウザに表示されません。next dev をそのまま公開しないことが前提です。

CMS

• WordPress：テーマの functions.php に remove_action('wp_head', 'wp_generator'); を追加するとgeneratorメタタグが出なくなります。WP_DEBUG は本番で false にします。
• その他の商用CMS：管理画面のメタ情報出力設定、またはテンプレートからgeneratorを削除します。

段階的な手順

設定後の確認方法

curl -sI https://www.example.lg.jp/ | grep -iE '^(server|x-powered-by|x-aspnet-version):'
curl -sI https://www.example.lg.jp/shisetsu/ | grep -iE '^(server|x-powered-by):'
curl -s https://www.example.lg.jp/ | grep -io '<meta[^>]*generator[^>]*>'
# 不正な値でのエラー応答を確認（自組織のサイトに限る）
curl -s 'https://www.example.lg.jp/search.php?id=%27' | grep -iE 'stack trace|sqlstate|uncaught|/var/www'

サイトを壊さないための注意点

• display_errors = Off にすると画面にエラーが出なくなるため、障害調査用に log_errors = On とログ保存先を必ず設定してください。
• Serverヘッダーを完全に消せない環境（一部のCDN・共有ホスティング）では、版数を出さない設定で十分です。
• 外部への不正値送信によるエラー確認は、自組織が管理するサイトに対してのみ実施してください。

よくある質問（FAQ）

参考資料

• OWASP ASVS 5.0.0 V13 Configuration
• OWASP ASVS 5.0.0 V16 Security Logging and Error Handling
• OWASP WSTG Fingerprint Web Server（WSTG-INFO-02）
• OWASP WSTG Improper Error Handling（WSTG-ERRH-01）
• Apache HTTP Server core（ServerTokens / ServerSignature）
• nginx ngx_http_core_module（server_tokens）
• Microsoft Learn Request Filtering（removeServerHeader）
• Next.js poweredByHeader

「下層・エラー応答のバージョン／デバッグ情報」と関連する診断項目

• サーバーバージョンを露出していないlow
• エラー応答のデバッグ情報high
• 生成ツール情報を露出していないlow
• Webサーバー／CMSのデフォルトファイルmedium
• 秘密情報らしき文字列がないcritical
• ソースマップ参照を公開していないmedium
• 本番HTMLにconsole.logを残していないlow
• 代表的な管理ファイルが公開されていないcritical