結論（公開ファイル・情報露出）
公開ファイル・情報露出の診断では、/.envや/.git/HEADなどの管理ファイル、.bakや.oldのバックアップ、ディレクトリ一覧、ソースマップの原文、HTMLに書かれたAPIキー、サーバーやCMSのバージョン情報、残されたセットアップ画面やテスト画面が外部から見えないかを確かめます。最優先は、管理ファイルの公開と秘密情報の埋め込みの2項目（最重要）です。
公開ファイル・情報露出の診断項目一覧（19項目）
管理ファイル、バックアップ、ソースマップ、ディレクトリ一覧、バージョン情報などの露出を確認します。各項目名から、意味・診断基準・リスク・具体的な対策を解説したページへ移動できます。
| No. | 診断項目 | 重大度 | 概要 |
|---|---|---|---|
| 24 | サーバーバージョンを露出していない | low | サーバーバージョンを露出していないかは、ServerやX-Powered-Byヘッダーにバージョン番号があるかで確認します。 |
| 25 | 秘密情報らしき文字列がない | critical | 秘密情報らしき文字列がないとは、公開HTMLにAPIキーや秘密鍵が書き込まれていない状態です。 |
| 26 | ソースマップ参照を公開していない | medium | ソースマップ参照を公開していないかは、本番HTMLに残る「//# sourceMappingURL=」注釈で確認します。 |
| 27 | 生成ツール情報を露出していない | low | 生成ツール情報を露出していないとは、HTMLにCMS名やバージョンを示すmeta generatorタグを出していない状態です。 |
| 28 | 本番HTMLにconsole.logを残していない | low | 本番HTMLにconsole.logを残していないとは、公開ページのスクリプトにデバッグ出力が残っていない状態です。 |
| 68 | 代表的な管理ファイルが公開されていない | critical | 代表的な管理ファイルが公開されていないかを、/.env・/.git/HEAD・/phpinfo.php・/server-status・/backup.zipの5種で確認する方法を… |
| 69 | security.txtを公開 | low | security.txtを公開すると、脆弱性を見つけた人が連絡先を迷わず見つけられます。 |
| 70 | security.txtの有効期限 | low | security.txtの有効期限（Expires）は必須項目で、RFC 3339形式・1年未満先が推奨です。 |
| 71 | robots.txtに機密パスを列挙していない | medium | robots.txtに機密パスを列挙していないかの確認方法を解説。 |
| 72 | sitemapに非公開ページを含めていない | medium | sitemapに非公開ページを含めていないかの確認方法を解説。 |
| 91 | security.txtのRFC 9116形式 | low | security.txtのRFC 9116形式は、/.well-known/にHTTPS・text/plain; charset=utf-8で置き、URI形式のContactと1… |
| 110 | Webサーバー／CMSのデフォルトファイル | medium | Webサーバー／CMSのデフォルトファイル（Apacheの/icons/・/server-info、WordPressのreadme.html等）が残ると製品や設定が特定されます。 |
| 111 | ディレクトリ一覧を公開していない | medium | ディレクトリ一覧を公開していないとは、index.htmlのないディレクトリでファイル名一覧（Index of /）を表示させないことです。 |
| 112 | 旧版・バックアップファイルの露出 | high | 旧版・バックアップファイルの露出とは、index.php.bakやconfig.php~などの残置ファイルがURLで取得できる状態です。 |
| 113 | ソースマップの原文公開 | medium | ソースマップの原文公開とは、.mapファイルのsourcesContentに元のソースコードが入り、誰でも取得できる状態です。 |
| 114 | CMSセットアップ／管理入口の露出 | medium | CMSセットアップ／管理入口の露出とは、WordPressやJoomlaの未完了のインストール画面や管理ログイン画面が外部から到達できる状態です。 |
| 115 | API仕様・GraphQL開発画面の公開 | medium | API仕様・GraphQL開発画面の公開とは、OpenAPI仕様書やSwagger UI、GraphiQLなどが本番で誰でも見られる状態です。 |
| 116 | 旧版・別ログイン・テスト画面の露出 | medium | 旧版・別ログイン・テスト画面の露出とは、リニューアル後の旧トップ・旧ログイン・/test/・/staging/などが公開領域に残る状態です。 |
| 122 | 下層・エラー応答のバージョン／デバッグ情報 | medium | 下層・エラー応答のバージョン／デバッグ情報は、トップ以外の下層ページの応答にServer・X-Powered-By・generatorの版数やスタックトレースが出ていないかを見る… |
公開ファイル・情報露出の診断とは
公開ファイル・情報露出の診断は、Webサーバーの公開領域に「本来は外から見えてはいけないもの」が残っていないかを確かめるものです。セキュリティ診断127項目のうち、管理ファイル、バックアップ、ソースコード、秘密情報、バージョン情報、使われなくなった入口などに関する19項目がこの分類に入ります。
Webサーバーは、公開ディレクトリに置かれたファイルを、URLさえ分かれば誰にでも返します。リンクを張っていないから見られない、ということはありません。攻撃者は決まったパスを順に試すだけで、こうしたファイルを見つけられます。
露出する情報の重さはさまざまです。APIキーやデータベースの接続情報が漏れれば、そのまま不正利用や侵入につながります。一方、サーバーやCMSのバージョン番号は単独では脆弱性ではありませんが、既知の脆弱性を持つ古いバージョンのサイトを絞り込む手掛かりになります。
19項目の全体像（6つのグループ）
この分類の19項目は、何が露出するかによって6つのグループに分けると整理しやすくなります。
| グループ | 診断項目 | 確認する内容 |
|---|---|---|
| 管理ファイル・バックアップの誤公開 | 「代表的な管理ファイルが公開されていない」、「旧版・バックアップファイルの露出」、「ディレクトリ一覧を公開していない」、「Webサーバー／CMSのデフォルトファイル」 | /.env・/.git/HEAD・/phpinfo.php・/server-status・/backup.zip、.bak・.old・~ 付きのファイル、「Index of /」の一覧ページ、Apacheの /icons/ やWordPressの /readme.html |
| 秘密情報・ソースコードの露出 | 「秘密情報らしき文字列がない」、「ソースマップ参照を公開していない」、「ソースマップの原文公開」、「本番HTMLにconsole.logを残していない」 | HTMLに書かれたAPIキーや秘密鍵、sourceMappingURLの注釈と .map ファイルの中身（sourcesContent）、開発時のデバッグ出力 |
| バージョン情報・デバッグ情報の露出 | 「サーバーバージョンを露出していない」、「生成ツール情報を露出していない」、「下層・エラー応答のバージョン／デバッグ情報」 | ServerやX-Powered-Byヘッダーの版数、meta generatorタグ、下層ページのスタックトレースやSQLエラー、サーバー内部パス |
| 残された入口・開発用画面 | 「CMSセットアップ／管理入口の露出」、「API仕様・GraphQL開発画面の公開」、「旧版・別ログイン・テスト画面の露出」 | 未完了のインストール画面や管理ログイン画面、OpenAPI仕様書やGraphiQL、index2.html・login2.php・/test/・/staging/ などの残存 |
| robots.txt・サイトマップ | 「robots.txtに機密パスを列挙していない」、「sitemapに非公開ページを含めていない」 | Disallow行の /admin/ や /backup/、サイトマップに載ったステージング環境やテストページのURL |
| 脆弱性の報告窓口 | 「security.txtを公開」、「security.txtの有効期限」、「security.txtのRFC 9116形式」 | /.well-known/security.txt の有無、Expiresの期限、Content-TypeやContactの書式 |
優先して確認すべき項目
重大度が「最重要（critical）」の2項目は、存在すれば認証情報や秘密情報の漏えいに直結するため、最初に確認します。いずれも重みは最大の5です。
- 代表的な管理ファイルが公開されていない：/.env（環境変数）、/.git/HEAD（Git管理情報）、/phpinfo.php、/server-status、/backup.zip を確認します。ファイル固有の中身まで一致した場合に×となり、ソースコードや認証情報の漏えいにつながる状態です。
- 秘密情報らしき文字列がない：OpenAI形式・AWS・GitHub・StripeのキーやPEM形式の秘密鍵ブロックがHTMLにあれば×です。HTMLは誰でもソースを表示できるため、画面に出していない変数の中にあっても漏えいと同じです。
次に「重要（high）」の「旧版・バックアップファイルの露出」を確認します。index.php.bak のように拡張子が変わったファイルは、Webサーバーがプログラムとして実行せず、ソースコードのままテキストで返すことがあります。診断は△ですが、ソースコードが返っていると確認できれば重大な事案として扱います。
その後、中程度（medium）の10項目に進みます。ディレクトリ一覧やデフォルトファイル、ソースマップの原文、未完了のCMSセットアップ画面は×になり得る項目なので、この中でも先に確認するとよいでしょう。サーバーのバージョン表示、generatorタグ、console.log、security.txtの3項目は重大度low・重み1で、基本の対策がそろった後に整えます。
直すときの進め方と注意点
情報露出の対策は「削除する」「サーバー設定で拒否する」「そもそも置かない運用にする」の3段階で考えると漏れが少なくなります。
- 見つかったものはまず削除し、漏れた前提で対処する：管理ファイルやバックアップ、APIキーが公開されていた場合、ファイルを消すだけでは足りません。すでに取得された可能性があるため、APIキーや接続情報を無効化・再発行します。
- サーバー設定で二重に拒否する：.env や .git、.bak・.old、.map などへのアクセスをApache・nginx・IISの設定で拒否し、ディレクトリ一覧（Indexes・autoindex・ディレクトリ参照）を無効にしておくと、うっかり置いた場合の被害を防げます。
- ビルドと配備の手順を見直す：ソースマップやconsole.logは、Vite・webpack・Next.jsなどのビルド設定で本番に含めないようにします。APIキーはHTMLやブラウザで動くJavaScriptに置かず、サーバー側のプロキシ経由で使う構成にします。
- バージョン表示は「補助的な対策」として抑える：ServerTokens Prod、expose_php = Off、display_errors = Off などでバージョンやデバッグ情報を外に出さないようにします。ただし本質的な対策はバージョンアップとパッチ適用です。なお ServerTokens は .htaccess では指定できず、expose_php は php.ini でしか設定できないため、サーバー側の設定ファイルで行います。
- 残された入口は資産台帳と照合して消す：旧トップページやテスト用ディレクトリは、名前だけでは現行ページか判断できません。台帳と照らして不要なものを削除し、必要な検証環境は公開ドメインから分離します。CMSの管理入口は接続元IP制限と多要素認証で守ります。
自治体・公共機関のサイトで特に注意すること
自治体や公共機関のサイトは、本体のCMSに加えて、委託先が作った特設サイトや防災マップ、施設予約などが同じドメインに同居していることが多く、情報露出の経路も増えがちです。よくある例として、次のようなものがあります。
- サーバー上で直接ファイルを編集した際の .bak や .old が残り、PHPのソースがテキストで見えてしまう。
- 委託業者が作成したインラインスクリプトに console.log が残っている、またはReactやVueで作った防災マップのソースマップに原文が含まれている。
- WordPressで立ち上げた観光・移住サイトの /readme.html や generatorタグ、ログイン画面がそのまま公開されている。
- 新しい特設サイトの準備中に、セットアップを終える前にDNSを公開してしまい、インストール画面に誰でも到達できる。
- リニューアル後も旧トップページやテスト用ディレクトリが残り、更新対象から外れた古いプログラムが動き続けている。
ドメインごとに管理者と委託先を一覧にし、公開ディレクトリの棚卸しと、診断による定期的な確認を組み合わせると、こうした露出を早く見つけられます。security.txtを置く場合は、Expiresを1年未満先の日時にし、期限の前に更新する運用まで決めておきます。
よくある質問（FAQ）
公開ファイル・情報露出の診断項目は、どの順番で直せばよいですか？
まず代表的な管理ファイルの公開と、HTMLへの秘密情報の埋め込み（いずれも最重要）を確認します。次に旧版・バックアップファイルの露出（重要）、続いてディレクトリ一覧、デフォルトファイル、ソースマップの原文、CMSのセットアップ画面などの中程度の項目を整え、最後にバージョン表示の抑制やsecurity.txtの整備を進めます。
公開ファイル・情報露出の診断で○なら、誤公開はないと言えますか？
言い切れません。管理ファイルは代表的な5パス、バックアップは起点ファイル1件×3種類の名前、ディレクトリ一覧は最大2ディレクトリだけを確認します。○は確認した範囲で見つからなかったという意味なので、公開ディレクトリの棚卸しや資産台帳との照合で補ってください。
サーバーのバージョン情報を隠せば、情報露出の対策は十分ですか？
十分ではありません。バージョンを隠すことは攻撃者の調査を遅らせる補助的な対策で、本質的な対策はバージョンアップとパッチ適用です。また、スタックトレースやSQLエラーなどのデバッグ情報は攻撃に直接使われるため、バージョン表示より優先して止めます。
robots.txtに管理画面のパスを書いて検索除外するのは、情報露出の対策になりますか？
なりません。robots.txtは誰でも取得でき、RFC 9309もアクセス制御の代わりにならないと明記しています。見られてはいけないものは認証で保護するか削除し、検索結果からの除外はnoindexで行います。
security.txtがないことも情報露出の診断で減点されますか？
△（要確認）になりますが、重大度はlow、重みは1です。security.txtは脆弱性の報告窓口を示すファイルで、/.well-known/security.txtにContactとExpiresを書いて置けば、報告の取りこぼしを低コストで減らせます。
公開ファイル・情報露出の19項目はまとめて確認できますか？
セキュリティAIチェッカーにURLを入力すると、この19項目を含む127項目を公開情報から自動で診断し、項目ごとの判定と改善の優先順位を表示します。