代表的な管理ファイルが公開されていないか（.env・.git・phpinfo・server-status・backup.zip）の確認と対策

代表的な管理ファイルが公開されていないとは

代表的な管理ファイルが公開されていないとは、Webサーバーの公開ディレクトリに、本来公開すべきでない管理用ファイルが置かれたままになっておらず、外部から取得できない状態のことです。セキュリティAIチェッカーは、代表的な5種類を対象に確認します。

いずれも「存在すれば即座に重大な情報漏えいにつながる」ファイルであるため、重大度critical・重み5で評価します。

robots.txtやサイトマップに書かれたパスから情報が漏れる問題は、「robots.txtに機密パスを列挙していない」と「sitemapに非公開ページを含めていない」で別に確認します。このページは、管理ファイルそのものが取得できてしまう問題に絞って解説します。

管理ファイルの誤公開はなぜ起きるのか

誤公開の主な原因

• デプロイ方法：開発環境で git clone したディレクトリをそのまま公開ディレクトリにすると、.git/ が一緒に公開されます。
• フレームワークの慣習：Laravel等は .env をプロジェクト直下に置きます。ドキュメントルートを public/ ではなくプロジェクト直下に設定すると .env が配信されます。
• 一時作業の放置：動作確認用の phpinfo.php、改修前に作った backup.zip を削除し忘れる。
• 既定設定：Apacheの server-status を全体に許可する設定、ディレクトリ単位のアクセス制御漏れ。

公的機関による注意喚起

スイスの国家サイバーセキュリティセンター（NCSC、現BACS）は、公開された .git フォルダから完全なソースコードと過去の変更履歴、DBパスワードやAPIキーが取得され得ると注意喚起し、2022年10月の公表で、約1,300の該当システムを確認し約400の宛先へ直接通知したとしています。同センターは .env や .DS_Store にも同様のリスクがあるとしています。

「200が返る＝公開」ではない理由

多くのCMSやCDNは、存在しないURLにもトップページや独自エラーページをステータス200で返します（ソフト404）。逆に、Apacheやnginxは静的ファイルへのRange付き要求に 206 Partial Content を返します。したがって、ステータスコードだけでは誤検知・見逃しの両方が起こります。セキュリティAIチェッカーはファイル固有の中身（シグネチャ）で判定します。

代表的な管理ファイルが公開されていないの診断基準（セキュリティAIチェッカー）

取得方法

• 診断の最終URLのオリジン（例: https://www.city.example.lg.jp）に対し、以下を並行してGETします。リダイレクトは追跡しません。
  • 基準用の存在しないパス /miniparse-security-review-not-found-probe
  • 上表の5パス
• 各要求は Range: bytes=0-4095 を付け、先頭最大4,096バイトだけを受け取ります。サーバーがRangeを無視して大きな応答を返した場合も、先頭4,096バイトで打ち切って判定に使います（大きなZIPやphpinfo出力でも取得失敗にしません）。タイムアウトは4秒です。
• ステータス200または206の応答だけを判定対象にします。

シグネチャ（公開と判定する条件）

判定条件

「エラーページと判断」は、基準パスが200/206を返すサイト（ソフト404）である場合、基準パスと同じ <title> を返した場合、または応答がHTMLである場合です。これらは誤検知として除外し、根拠欄に列挙します。

判定の限界

代表的な5パスのみの確認です。WAF等が診断の要求を遮断して5パスすべてが接続失敗・タイムアウトになった場合は対象外（判定不能）で、非公開を確認できたわけではありません。一部のパスだけ応答がない場合は ○ になり得るため、後述の確認方法で自ら確かめてください。

なお、診断の最後にトップページを取り直し、HTTP 403/429または無応答に変わっていた場合は、レポートを返さず診断全体をエラーにします。.svn/、.DS_Store、*.bak、wp-config.php~、/old/、ディレクトリ一覧などは別項目または手動確認の対象です。○ でも「誤公開がない」ことの保証にはなりません。

自治体サイトでの判定例

管理ファイルが公開されているとどんなリスクがあるか

• .env：DB・メール・外部APIの認証情報が漏れると、住民情報を含むDBへの不正アクセスや、自治体ドメインからのスパム送信に直結します。
• .git：ソースコード全体と過去のコミットが復元でき、削除済みのパスワードや未修正の脆弱性が見つかることがあります。
• phpinfo：ドキュメントルートの絶対パス、読み込まれた拡張、環境変数（クラウド環境ではキーを含むことがある）を表示し、他の攻撃の足がかりになります。
• server-status：処理中のリクエストURL（クエリ文字列にトークンや個人情報が含まれる場合を含む）と接続元IPを表示します。
• バックアップアーカイブ：上記すべてを一度に含み得ます。

管理ファイルの公開を防ぐ方法（Apache・nginx・IIS・Next.js）

1. まず削除・移動する

最も確実なのは、公開ディレクトリから該当ファイルを物理的に取り除くことです。.env はドキュメントルートの外へ置き、ドキュメントルートをフレームワークの public/ に設定します。漏えいの可能性がある認証情報は、削除と同時に**必ず再発行（ローテーション）**します。

2. Webサーバーで拒否する（多層防御）

Apache（.htaccess または VirtualHost）

# ドットで始まるファイル・ディレクトリを拒否（.well-known は除外）
<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteRule "(^|/)\.(?!well-known/)" - [F]
</IfModule>

# バックアップ・設定系の拡張子を拒否
<FilesMatch "\.(?:zip|tar|gz|bak|old|orig|sql|env|log|ini)$">
  Require all denied
</FilesMatch>

# phpinfo の撤去が原則。どうしても残る場合
<Files "phpinfo.php">
  Require all denied
</Files>

server-status は VirtualHost側で管理者端末のみに限定します（.htaccessでは設定できません）。

<Location "/server-status">
  SetHandler server-status
  Require ip 127.0.0.1 192.0.2.10
</Location>

nginx

location ~ /\.(?!well-known/) { deny all; return 404; }
location ~* \.(?:zip|tar|gz|bak|old|orig|sql|env|log)$ { deny all; return 404; }
location = /phpinfo.php { return 404; }

IIS（web.config）

<system.webServer>
  <security>
    <requestFiltering>
      <hiddenSegments>
        <add segment=".git" />
        <add segment=".env" />
      </hiddenSegments>
      <fileExtensions allowUnlisted="true">
        <add fileExtension=".zip" allowed="false" />
        <add fileExtension=".bak" allowed="false" />
      </fileExtensions>
    </requestFiltering>
  </security>
</system.webServer>

Next.js（Vercel）

public/ 配下だけが静的配信されるため、.env* や .git を public/ に置かないことが基本です。ビルド成果物に不要ファイルが混入していないか、デプロイ前に public/ の一覧を確認します。

3. デプロイ手順を見直す

• git clone ではなく、ビルド済み成果物だけを転送する（rsync --exclude '.git' --exclude '.env' 等）。
• CMSの更新作業でバックアップを作る場合は、公開ディレクトリ外に保存し、作業後に削除する。
• 調達仕様書・保守契約に「公開領域に管理ファイルを置かない」「納品時に確認する」を明記する。

4. 確認方法

for p in /.env /.git/HEAD /phpinfo.php /server-status /backup.zip; do
  printf '%s ' "$p"; curl -s -o /dev/null -w '%{http_code}\n' "https://www.city.example.lg.jp$p"
done
curl -s -H 'Range: bytes=0-200' https://www.city.example.lg.jp/.git/HEAD

404または403で、中身が当該ファイルでないことを確認します。対処後はセキュリティAIチェッカーで再診断し、根拠欄に公開が確認された対象が残っていないことを確かめます。

サイトを壊さないための注意点（ガードレール）

• ドットファイル拒否のルールでは /.well-known/ を必ず除外します（security.txt、ACMEのHTTP-01認証、各種ドメイン認証で使います）。除外しないと証明書の自動更新が失敗することがあります。security.txtの設置は「security.txtを公開」で確認します。
• 拡張子拒否は、住民向けに配布しているZIPやCSV（オープンデータ等）まで止めないよう、配布用ディレクトリを確認してから適用します。
• 設定変更後は、トップページ・主要ページ・ダウンロードファイルが表示できることを確認します。

よくある質問（FAQ）

参考資料

• OWASP ASVS 5.0.0 V13 Configuration
• OWASP WSTG-CONF-04 Review Old Backup and Unreferenced Files for Sensitive Information
• BACS（旧NCSC スイス）Unprotected .git folders on the internet pose a security risk
• IPA 安全なウェブサイトの作り方
• RFC 9110 HTTP Semantics（206 Partial Content / Range）

「代表的な管理ファイルが公開されていない」と関連する診断項目

• robots.txtに機密パスを列挙していないmedium
• sitemapに非公開ページを含めていないmedium
• security.txtを公開low
• 秘密情報らしき文字列がないcritical
• 存在しないURLのステータスmedium
• エラー応答のデバッグ情報high
• ディレクトリ一覧を公開していないmedium
• 旧版・バックアップファイルの露出high