.gitや.envが公開されていないか確認する方法と、見つかった時の対処

最初に確認する2つのURLと、合否の目安

最初に確かめるのは、自社サイトの /.git/HEAD と /.env です。.git/HEAD はGitの管理フォルダに必ずある1行のファイルで、.gitフォルダが外から見えるかの目印になります。example.com を自社のドメインに置き換え、ターミナルで次のコマンドを実行します。

curl -I https://example.com/.git/HEAD
curl -I https://example.com/.env

# 出力の例(1行目の数字が応答コード)
HTTP/2 404
content-type: text/html

結果は、1行目の数字で次のように読みます。

• 404か403: その場所からは読めません。別の場所と入口は、後の章で確かめます。
• 200: ブラウザで同じURLを開いて中身を見ます。ref: refs/heads/main のような1行や、APP_KEY= などの行が並べば公開中です。
• 301や302: 別のURLへの転送です。curl -IL で転送先までたどり、最後の数字で判断します。

.gitと.envが公開される3つの経路

.gitや.envがURLで読めるのは、Webサーバーが外に配る「公開ディレクトリ」(ドキュメントルート)の中に置かれているからです。公開ディレクトリの外にあるファイルには、URLでは届きません。中に入り込む経路は、主に次の3つです。

1. プロジェクトの直下を公開している: 本来は public などの下位フォルダだけを公開する構成で、プロジェクト全体を公開している状態です。Laravelの公式文書も、プロジェクトの直下から配信すると多くの機密設定ファイルが公開されると注意しています。
2. 公開ディレクトリでGitを使う: 公開ディレクトリの中で git clone や git pull を実行して運用すると、.gitフォルダがそのまま残ります。FTPでプロジェクトのフォルダごとアップロードした時や、WordPressのテーマを開発フォルダのまま置いた時も同じです。
3. バックアップと作業ファイルを残す: 移行作業で作ったzipやデータベースのダンプ、サーバー上の編集で生まれた wp-config.php.bak などの控えが残るケースです。エディターが自動で作る、名前が ~ で終わるファイルや .swp も含みます。

公開されると何が読まれるか

.gitフォルダが読めると、ソースコードと変更の履歴が外に出ます。.envが読めると、書かれた鍵とパスワードがそのまま外に出ます。どちらも、一度読まれた値は相手の手元に残り、後から取り消せません。

.gitフォルダから読まれるもの

• ソースコード一式と変更の履歴。今は消したファイルや、過去に一度コミットしたパスワードも履歴に残ります。
• .git/config に書かれた接続先のURL。Gitの公式文書のとおり、URLには ユーザー名:パスワード@ の形で認証情報を書けます。トークン入りのURLで clone していると、その値も読まれます。
• コミットした人の名前とメールアドレス、ブランチ名など、開発体制の手がかり。

.envから読まれるもの

.envは、フレームワークやアプリが起動時に読み込む設定ファイルです。データベースの接続先とパスワード、決済、メール配信、クラウドのAPIキー、Laravelの APP_KEY のような暗号鍵が並ぶのが一般的です。.envが読まれた時点で、書かれていた値はすべて漏洩したものとして扱います。

.gitと.env以外にも、公開ディレクトリに残りやすいファイルがあります。主な例は次の表のとおりです。

自分のサイトで公開を確認する手順と、見落としやすい場所

確認は、ブラウザで中身を見る方法と、curlで応答コードを並べる方法を組み合わせます。見落としやすいのは、下位フォルダ、別のホスト名、HTTPの側、CDNの裏のサーバーです。

ブラウザで中身を見る

アドレス欄に https://example.com/.git/HEAD を入れて開きます。ref: refs/heads/main のような1行が出れば、.gitフォルダは公開中です。.env で KEY=値 の行が並んだ場合も同じで、表示された値は画面共有やスクリーンショットで広げないようにします。

curlで応答コードとサイズを並べる

候補をまとめて確かめるなら、応答コードと受け取ったバイト数を1行ずつ並べます。サイズがすべて同じなら、同じエラーページかトップページが返っている目安です。macOSやLinuxのターミナル、WindowsならGit BashかWSLで動きます。

for p in /.git/HEAD /.git/config /.env /.env.production /wp-config.php.bak; do
  printf '%-22s ' "$p"
  curl -s -o /dev/null -w '%{http_code} %{size_download}B' "https://example.com$p"
  echo
done

# 出力の例
/.git/HEAD             404 153B
/.env                  404 153B

見落としやすい場所と入口

トップの /.git/HEAD が404でも、別の場所や入口から読めることがあります。次の4つも確かめます。

• 下位フォルダ: /blog/.git/HEAD や /wp-content/themes/テーマ名/.git/HEAD など、Gitで管理していたフォルダの直下。
• 別のホスト名: www の有無、stg. や dev. などの検証環境、使わなくなった旧ドメイン。
• HTTPとHTTPS: サーバーの設定が別々で、片方だけに拒否の設定が入っていることがあります。
• CDNの裏のサーバー: CDNやWAFで止めていても、元のサーバー(オリジン)にIPアドレスで届くと、その遮断を通りません。

# ホスト名と、HTTP、HTTPSの組み合わせを確かめる
for s in http https; do
  for h in example.com www.example.com; do
    printf '%-5s %-18s ' "$s" "$h"
    curl -s -o /dev/null -w '%{http_code}' "$s://$h/.env"; echo
  done
done

# CDNを通さず、オリジン(例: 203.0.113.10)へ直接確かめる
curl -sI --resolve example.com:443:203.0.113.10 https://example.com/.env | head -n 1

候補を1つずつ試す手間を省くなら、自社の無料ツール「Webサイトのセキュリティチェック」も使えます。対象は、.git、.svn、.env、wp-config.phpの控え、SQLダンプ、バックアップの圧縮ファイルです。ページの取得(GET、HEAD、OPTIONS)だけで確かめ、診断できるのは自社または管理権限のあるサイトに限られます。

200、403、404の読み方と、404でも安全と言い切れない理由

応答コードは「その場所から読めるか」を示すだけで、安全の証明ではありません。200は中身を見るまで判断できず、404は確かめた経路の結果でしかないからです。

表の「ソフト404」はGoogleの用語で、存在しないページにも200を返す状態を指します。迷った時は、次の図の順にたどります。

404でも安全と言い切れない4つの理由

1. 確かめた経路の結果でしかない: 前の章の下位フォルダ、別のホスト名、HTTP、オリジンは、それぞれ別に確かめる必要があります。
2. 過去の公開は分からない: 今日の404は、昨日まで読めなかった証明になりません。過去の公開は、アクセスログで確かめます。
3. HEADとGETで応答が違う場合がある: HTTPの仕様(RFC 9110)は、HEADにGETと同じヘッダーを返すことを『SHOULD』(推奨)にとどめています。curl -I が404や405でも、-I を外したGETでも確かめます。
4. 拒否が一部のファイルにしか効いていない: 設定の書き方によっては、/.env は403でも /.git/HEAD は200のまま、という状態が起きます。実例は、後の章のApacheの表に載せています。

他人のサイトを調べてはいけない理由

他人のサイトに .git や .env があるかを、管理者の許可なく確かめるのはやめてください。見つけた値を使えば法律に触れるおそれがあり、URLを試すこと自体も、相手のログには攻撃の下調べと同じ形で残ります。主な論点は次の3つです。

• 不正アクセス禁止法: 警察庁の解説によると、「不正アクセス行為」には2つの類型があります。他人のIDやパスワードを無断で入力して利用制限を外す行為と、設定ミスなどの不備を突いて制限を免れる行為です。.envで見つけたパスワードでデータベースや管理画面に入れば、これに当たるおそれがあります。
• 取得、保管、提供: 不正アクセスに使う目的で他人のIDやパスワードを取得、保管することや、正当な理由なく人に渡すことも禁じられています。同じ解説は、検索中にたまたま表示された場合は、取得の罪に当たらないとも説明しています。
• 試し方と負荷: IPAなどが定める情報セキュリティ早期警戒パートナーシップガイドラインは、URLの数字を積極的に多数変えて試す行為を例に挙げています。こうした行為は、制限を免れる目的とみなされる可能性があるという説明です。故意にサーバーの性能を落とす行為は、業務妨害罪に触れる可能性があるとも述べています。

同ガイドラインは、IPAが届出を受け付けても、発見の方法についての法的な責任は免除されないと明記しています。善意の確認であっても、許可の無い調査は自分を守る根拠になりません。

漏洩が見つかった時の対処: 優先順位つきの7手順

公開を見つけたら、すでに読まれた前提で、公開の停止、鍵の作り直し、ログの調査の順に進めます。1と2を最優先で終え、調査と連絡はその後に回します。

1. 公開を止めるファイルやフォルダを公開ディレクトリの外へ移すか、後の章の拒否の設定を入れ、URLが404か403になったことを確かめます。消す前に、書かれていた値の一覧と、ファイルの更新日時を控えます。アクセスログは調査に使うので、消さずに残してください。
2. 鍵とパスワードを失効させ、作り直す書かれていた値は、使っていないものも含めてすべて対象です。.gitが公開されていた場合は、履歴の全期間に一度でもコミットされた値まで含めます。新しい値は、公開ディレクトリの外にある設定に入れてから切り替えます。
3. アクセスログで読まれたかを調べる該当URLに、いつ、どのIPアドレスへ、何バイトを返したかを確かめます。コマンドの例は、この手順の下に載せています。
4. 不正利用の跡を調べるデータベースへの見知らぬ接続や操作、管理画面の不明なアカウント、クラウドやAPIの請求額、メールの送信履歴を確かめます。
5. Git履歴から取り除くリポジトリに秘密の値が入っていた場合は、履歴からも取り除きます。手順と注意点は次の章で説明します。
6. 関係者に連絡する社内の責任者、制作や保守の委託先、APIの提供元に、何が、いつから公開されていたかを伝えます。個人情報を扱うデータベースに入られたおそれがあれば、個人情報保護委員会への報告が必要かを確かめます。
7. 再発防止を入れ、もう一度確かめる後の章の配置と設定を入れたあと、最初の章のcurlで、すべての場所と入口が404か403になることを確かめます。

手順2で作り直す主な値と、切り替える時の注意は次のとおりです。

Laravelは、旧鍵を APP_PREVIOUS_KEYS に並べると、旧鍵で暗号化した値も復号できる仕組みを持っています。漏洩した鍵をここに残すと、その鍵で作られた値も受け付け続けるため、保存データを新しい鍵で暗号化し直したら外します。

手順3のログ確認では、該当URLへの要求のうち、200で返したものを抜き出します。ログの場所は、Nginxなら /var/log/nginx/、Apacheなら /var/log/apache2/ や /var/log/httpd/ が一般的です。レンタルサーバーでは、管理画面から取り出したログに同じ検索をかけます。

# 200で返した .git と .env への要求(日時、IPアドレス、URL、返したバイト数)
zgrep -hE '/[.](git|env)' /var/log/nginx/access.log* |
  awk '$9 == 200 {print $4, $1, $7, $10}'

# IPアドレスごとの件数
zgrep -hE '/[.](git|env)' /var/log/nginx/access.log* |
  awk '$9 == 200 {print $1}' | sort | uniq -c | sort -rn

標準のログ形式(combined)では、9番目の欄が応答コード、10番目が返したバイト数です。バイト数がトップページやエラーページと同じなら、ファイルの中身は渡っていない可能性が高いと読めます。見知らぬIPアドレスの国や組織は、自社の無料ツール「IPアドレスから位置を調べるツール」でも調べられますが、結果は目安です。

Git履歴から消すだけでは足りない理由と、消す手順

Git履歴から秘密の値を消しても、すでに複製されたものは消えません。公開されていた.gitを取得した人の手元、開発者のクローン、フォークには古い履歴が残ります。GitHubの公式文書も、秘密の値は最初に失効させるか作り直すべきだとしています。

そのうえで履歴から取り除くのは、古い値の再利用や、別の人による再公開を防ぐためです。GitHubが示す手順の要点は、新しいクローンで書き換えて、まとめて送り直すことです。

# 1. 作業用に、新しくクローンする
git clone https://github.com/組織名/リポジトリ名.git
cd リポジトリ名

# 2. 全履歴から .env を取り除く(git-filter-repo 2.47以降)
git filter-repo --sensitive-data-removal --invert-paths --path .env

# 3. 書き換えた履歴を送る(共同作業者へ事前に知らせる)
git push --force --mirror origin

# 4. 今後は追跡しないよう .gitignore に加える
echo ".env" >> .gitignore
git add .gitignore
git commit -m "Ignore .env"
git push origin main

書き換えのあと、古いクローンを持つ人はクローンし直します。GitHubの文書は、古い履歴から作ったブランチを、mergeではなくrebaseするよう求めています。GitHubの画面に残るキャッシュや、プルリクエストが参照する古いコミットの削除は、GitHubサポートへの依頼が必要です。

再発防止の基本: 公開ディレクトリの外に置く

根本の対策は、秘密の値と管理用のフォルダを、公開ディレクトリの外に置く配置にすることです。サーバーの拒否設定は、移行や設定の書き換えで消えることがあるため、2段目の守りと考えます。

• Laravelなど: 公開ディレクトリを public に設定し、.env や .git はその1つ上に置きます。
• WordPress: 公式の手引きのとおり、wp-config.php はインストール先の1つ上の階層へ移しても動きます。
• バックアップ: 圧縮ファイルやダンプは、公開ディレクトリの外か別の保管場所に置き、作業後に消すことを手順書に入れます。
• 公開先を変えられないサーバー: サーバー会社の案内で、公開フォルダの外に置ける場所があるかを確かめます。

サーバー設定で拒否する: Apache、Nginx、WordPressの例

配置を直すまでの応急処置と、置き忘れへの備えとして、ドットで始まるファイルとフォルダ、バックアップのような名前を拒否します。ここでの設定例と表の応答は、nginx 1.30.5とApache 2.4.69での動作確認に基づきます。

Apache(.htaccess)

公開ディレクトリの .htaccess の先頭に、次の2行を書きます。正規表現の [.] は、ドットそのものを表す書き方です。

# ドットで始まるファイルとフォルダを 404 にする(.well-known は除く)
RedirectMatch 404 /[.](?!well-known/)
# バックアップや作業用のファイルを 404 にする
RedirectMatch 404 (?i)([.](bak|old|orig|save|swp|sql)|~)$

.well-known を除くのは、SSL/TLS証明書の自動更新(Let’s Encryptなど)や security.txt がこの場所を使うためです。除外を忘れると証明書の更新が失敗するので、更新の状況は「SSL/TLS証明書のチェック方法」の手順で確かめます。サイトでzipなどを配布していなければ、2行目に zip や gz を足せます。

表の「FilesMatchだけ」は、<FilesMatch "^[.]"> と Require all denied の組み合わせです。Apacheの公式文書のとおり、FilesMatchはファイル名(パスの最後の部分)だけを見ます。そのため /.git/HEAD は HEAD という名前で判定され、拒否されません。

.htaccessは、サーバーが上書きを許している時だけ効く仕組みです。許可が無いとエラーも出ずに何も効かないため、書いた後は /.env が404になるかをcurlで確かめます。

一覧表示を止める Options -Indexes は、上書きの許可が無いと、書いただけでサイト全体が500エラーになります。追加したら、すぐにトップページを開いて確かめてください。

Nginx

Nginxは.htaccessを読まないため、サーバー設定の server ブロックに書きます。書いたら nginx -t で構文を確かめてから、設定を再読み込みします。

# ほかの正規表現の location より前に書く
location ~ /[.](?!well-known/) {
    return 404;
}
location ~* ([.](bak|old|orig|save|swp|sql)|~)$ {
    return 404;
}

# ^~ を付けた location の中では上の規則が効かないため、中にも書く
location ^~ /assets/ {
    location ~ /[.] {
        return 404;
    }
}

Nginxの公式文書のとおり、正規表現のlocationは書いた順に調べられ、最初に当てはまったものが使われます。静的ファイル用の正規表現を先に書くと、/.notes.txt のようなファイルがそちらで配られます。また、^~ を付けたlocationの下では正規表現が調べられないため、例の /assets/.env は中に拒否を書くまで200のままです。

WordPress

Apacheで動くWordPressでは、上の2行に wp-config.php の拒否を加えたものを、.htaccess の先頭に置く形が基本です。WordPressの公式の手引きによると、# BEGIN WordPress と # END WordPress の間は、WordPressが書き換えることがあります。そのため、追加する行はこの範囲の外に書きます。

# 既存の「# BEGIN WordPress」より上に、次の行を足す
RedirectMatch 404 /[.](?!well-known/)
RedirectMatch 404 (?i)([.](bak|old|orig|save|swp|sql)|~)$
<Files "wp-config.php">
    Require all denied
</Files>

# (この下に、WordPressが管理する「# BEGIN WordPress」から
#  「# END WordPress」までが続く。その間には書き足さない)

あわせて、wp-config.php の WP_DEBUG_LOG の値も確認が必要です。true にすると、エラーは既定で wp-content/debug.log に書かれ、公開ディレクトリの中に残ります。本体やプラグインの更新状況も合わせて点検するなら、「WordPressの脆弱性を確認する方法」の手順が使えます。

サーバー設定を開く機会に、セキュリティヘッダーも一緒に見直すと、作業が1回で済みます。設定例は「セキュリティヘッダーの設定方法」にまとめています。

デプロイ手順と.gitignoreで、混入を防ぐ

.gitや.envを公開先へ持ち込まない手順にすれば、拒否の設定に頼る場面が減ります。要点は、公開するファイルだけを、決まった手順で送ることです。

• 送るのはビルド後の成果物だけ: dist や public など、公開用のフォルダだけを送ります。git archive で作るアーカイブには、.gitフォルダが入りません。
• 公開ディレクトリでcloneしない: Gitの操作は公開ディレクトリの外で行い、成果物だけを配置します。
• FTPでフォルダごと上げない: 送る前に、ドットで始まる隠しファイルを表示して、中身を確かめます。
• 検証環境も同じ扱いにする: stg. などの検証環境は、IP制限やBasic認証で関係者だけに絞ります。

.gitignoreは、秘密の値をリポジトリに入れないための設定です。ただしGitの公式文書のとおり、すでに追跡しているファイルには効かないため、git rm --cached で追跡を外してから使います。

# .gitignore の例(.env.example だけは共有する)
.env
.env.*
!.env.example
*.log
*.sql
*.bak

# すでに追跡している .env を外す(手元のファイルは残る)
git rm --cached .env

デプロイ前に自動で止める

人の注意に頼らず、公開用のフォルダに置いてはいけないファイルがあれば、デプロイを止める確認を手順に組み込みます。次の例は、見つかった時に終了コード1で止まるため、CIの1工程として使えます。

# 公開するフォルダ(ここでは dist)に、置いてはいけないファイルが無いか確かめる
found=$(find dist -name '.git' -o -name '.env*' -o -name '*.sql' -o -name '*.bak')
if [ -n "$found" ]; then
  echo "公開してはいけないファイルがあります:"
  echo "$found"
  exit 1
fi

コミットの段階では、OSSのGitleaksなど、パスワードやAPIキーの形の文字列を見つける道具を、コミット前の確認(pre-commit)に入れられます。GitHubの公開リポジトリでは、シークレットスキャンが無料で自動的に動く仕組みです。公開後は、同じURLを外から定期的に確かめる処理をサーバー監視の項目に加えると、設定の巻き戻りに気づけます。

公開前と更新後のチェックリスト

• 公開ディレクトリが public などの公開用フォルダだけを指している
• /.git/HEAD、/.env、/wp-config.php.bak が、すべてのホスト名とHTTP、HTTPSで404か403になる
• CDNを使う場合、オリジンへ直接確かめても同じ結果になる
• 拒否の設定を入れた後も、トップページと /.well-known/ の下が表示される
• 公開ディレクトリに、zip、SQLダンプ、debug.log、phpinfoのページが残っていない
• .gitignoreに .env が入り、git ls-files の一覧に .env が出てこない
• デプロイの手順に、置いてはいけないファイルの確認が入っている

サーバーの入れ替え、デプロイ方法の変更、制作会社の交代の後が、このリストを最初からやり直す時期です。公開ファイル以外の点検項目は、「Webサイトのセキュリティチェック項目30選」にまとめています。無料の簡易チェックで分かる範囲と、専門の診断が要る場面の違いは、「簡易チェックと脆弱性診断の違い」で説明しています。

よくある質問