API キーの漏洩経路を 7 つに整理する｜.env 探しへの対策手順

この記事の要点

• API キー漏洩の原因は、Git 履歴・フロントエンドの成果物・公開設定ミス・ログ・外部ツール・サーバーの公開ファイル・人為的な共有の 7 経路に整理でき、「.env を直接盗まれる」ケースはその一部にすぎません。
• 公開サイトには /.env を探すアクセスが日常的に届くため、Web ルートに秘密情報を置かない設計と、漏れた前提の即時失効手順を用意しておくことが最も効果的な対策です。
• 対策の優先順位は「失効できる体制 → 漏らさない構成 → 検知の自動化」の順です。コミット前スキャンと GitHub の Push Protection を組み合わせると、手間が小さい割に効果が出ます。

API キーはどこから漏れるのか

「API キー 漏洩」と検索する人の多くは、次の疑問を持っています。

• 自分のサイトに /.env へのアクセスが来ている。大丈夫なのか
• 漏れるとしたら、どこが危ないのか
• 漏れたら何をすればよいのか

参考にしたのは、自サイトに届いた .env 探し 1,566 件を分析した Qiita の記事です（https://qiita.com/songchong/items/02672765fe53f911a1a0）。タイトルによると、公開事例を 7 つの経路に分けています。

本記事は、その題材を「自分の環境で何を点検するか」という視点で組み直したものです。7 つの経路の分け方は筆者の整理であり、元記事の分類と一致するとは限りません。件数以外の数値は載せません。

自分のサイトに来る .env 探しの正体

何が起きているのか

公開 Web サーバーには、/.env や /.git/config、/wp-config.php.bak などを機械的に探すアクセスが届きます。狙いは、設定ファイルの置き忘れです。

これらは特定のサイトを狙った攻撃ではありません。インターネット全体を総当たりで調べる自動スキャンの一種です。アクセスログに 404 が並んでいても、すぐに侵害されたとは言えません。

本当に危ないのはどんなときか

危険なのは、ログの中に「200 が返っている」行があるときです。次のコマンドで確認できます。

# nginx のアクセスログで、.env 系へのアクセスと応答コードを見る
grep -E '/\.(env|git)' /var/log/nginx/access.log | awk '{print $9}' | sort | uniq -c

200 や 403 以外が混ざっていたら、そのパスにファイルが存在する可能性があります。まず応答内容を確認してください。

漏洩経路を 7 つに分けて整理する

#	経路	典型例	主な対策
1	Git 履歴	誤コミット、後で消したキー	Push Protection、履歴の書き換え、失効
2	フロントエンド成果物	JS バンドル、ソースマップ	秘密鍵をブラウザに渡さない
3	Web ルートの公開ファイル	/.env、バックアップファイル	ドキュメントルートの外に置く
4	ログ・エラー画面	デバッグ出力、スタックトレース	マスキング、本番でデバッグ無効化
5	CI/CD・コンテナ	イメージの層、ビルドログ	シークレット機能、マルチステージビルド
6	外部ツール・チャット	貼り付けたキー、画面共有	共有手段の統一、短寿命トークン
7	依存・第三者サービス	侵害されたパッケージ、連携アプリ	権限の最小化、定期ローテーション

1. Git 履歴

最も多く語られる経路です。ファイルを消しても、履歴には残ります。公開リポジトリなら、誰でもコミットを辿れます。

GitHub は、既知の形式のシークレットをコミット時に検知する機能を提供しています（https://docs.github.com/en/code-security/secret-scanning）。Push Protection は、push の時点でブロックする仕組みです。

2. フロントエンド成果物

ブラウザに配る JavaScript に、キーが入っているパターンです。環境変数を埋め込む設定のまま、秘密鍵を渡してしまいます。

たとえば Next.js は、NEXT_PUBLIC_ で始まる変数をブラウザ向けに公開する仕様です（https://nextjs.org/docs/app/guides/environment-variables）。この接頭辞を付けた時点で、公開前提になります。ソースマップを本番に置く場合も、元のコードが読めます。

3. Web ルートの公開ファイル

自サイトに届く .env 探しが狙うのは、この経路です。ドキュメントルートの配下に .env を置くと、設定次第で URL から取得できます。

対策は単純です。設定ファイルを Web ルートの外に置きます。置けない場合は、Web サーバー側でドットファイルを拒否します。

# nginx: ドットで始まるファイルへのアクセスを拒否
location ~ /\. {
    deny all;
    return 404;
}

4. ログ・エラー画面

デバッグモードのまま本番に出すと、環境変数を含むエラー画面が表示されることがあります。ログに Authorization ヘッダーをそのまま出す実装も同じ問題です。

ログ出力の段階で、キーの形式をマスクしてください。

5. CI/CD・コンテナ

Docker イメージは層の履歴を持ちます。ビルド中に COPY .env や ENV KEY=... を書くと、後から消しても層に残ります。ビルド用の秘密は BuildKit の secret マウントなどで渡すと安全です。

6. 外部ツール・チャット

チャットへの貼り付け、画面共有、AI アシスタントへの入力が該当します。技術的な欠陥ではなく、運用の問題です。

共有手段を 1 つに決めてください。パスワードマネージャーやシークレット管理サービスに寄せると、経路が減ります。

7. 依存・第三者サービス

利用中のパッケージや連携アプリが侵害されると、そこから環境変数が読み取られる恐れがあります。自分では防ぎにくい経路です。

だからこそ、キーの権限は最小にします。侵害されても被害が小さくなるからです。

漏れた前提で動く：失効の手順

検知より先に決めておくべきは、失効の手順です。漏れたら、次の順で動きます。

1. 該当キーを発行元の管理画面で無効化する
2. 新しいキーを発行し、本番の設定を差し替える
3. 利用履歴を確認し、不審な呼び出しがないか調べる
4. 原因の経路を特定して塞ぐ

履歴からファイルを消すことは、4 番目以降の話です。まず失効します。先に履歴を書き換えても、すでにコピーされた可能性は消えません。

漏らさない仕組みを入れる

コミット前に gitleaks で検査する

gitleaks は、リポジトリのシークレットを検出するオープンソースのツールです（https://github.com/gitleaks/gitleaks）。

# リポジトリ全体の履歴を検査
gitleaks detect --source . -v

# コミット前フックとして、ステージ済みの変更だけ検査
gitleaks protect --staged -v

導入時は、まず過去の履歴に対して一度実行してください。古いキーが見つかることがあります。

設計の基本は環境変数と分離

設定を環境変数に置く考え方は、Twelve-Factor App にまとまっています（https://12factor.net/config）。コードと設定を分けることで、誤ってコミットする機会が減ります。

さらに、.gitignore に .env を入れ、代わりに .env.example をコミットします。中身はダミーの値だけにします。

一次的な所感：件数より「置き場所」の問い

元記事と公式ドキュメントを読み比べて、気づいた点があります。1,566 件という数字は大きく見えますが、中身は自動スキャンの試行回数です。重要なのは、そのうち何件が 200 を返したかでした。

自分のログで同じ確認をするだけで、ほとんどの人は安心できるはずです。ただし、手元で全経路を再現して試したわけではありません。経路 4〜7 は、公開されている解説からの整理です。

デメリット・向いていない人・うまくいかないケース

ここまでの対策には、限界もあります。

• スキャナーは万能ではありません。 独自形式のキーや、暗号化・分割された文字列は検知されにくいです。
• 誤検知の運用コストがあります。 小さなチームでは、無視ルールが増えて形骸化することがあります。
• 履歴の書き換えは副作用が大きいです。 チーム開発で強制 push をすると、他の人の作業を壊します。実行前に必ず合意を取ってください。
• 個人の趣味サイトでは過剰な場合もあります。 ただし、決済や個人情報に触れるキーを扱うなら、規模にかかわらず必要です。
• フロントエンドだけで完結する設計では、守れません。 ブラウザに渡した値は、すべて見られる前提で扱います。

次に取る行動

今日できることは 3 つです。

1. 自サイトのアクセスログで、/.env への応答コードを確認する
2. 手元の主要リポジトリで gitleaks detect を一度実行する
3. 使っている API キーの失効手順を、発行元ごとにメモしておく

残る問いは、ひとつです。いまのキーを、5 分以内に差し替えられますか。

よくある質問

サイトに /.env へのアクセスが来ていたら、侵害されていますか

アクセスが来ただけでは侵害されていません。自動スキャンが全体に送っている試行です。応答コードが 404 や 403 なら、ファイルは取得されていません。200 が返っていたら、すぐに該当キーを失効してください。

.env をドキュメントルートに置くとなぜ危険なのですか

Web サーバーが、ファイルを静的ファイルとして配信してしまう可能性があるからです。URL を直接指定されると、中身が読み取られます。設定ファイルは、ドキュメントルートの外に置くのが基本です。

GitHub に API キーをコミットしてしまったらどうすればよいですか

まず発行元でキーを失効し、新しいキーに差し替えてください。履歴の削除はその後です。公開リポジトリでは、コピーされた可能性を前提に考えます。

コミットしたファイルを削除すれば安全ですか

安全ではありません。Git は過去のコミットを保持しているため、履歴から取り出せます。履歴の書き換えは補助的な手段で、失効が先です。

フロントエンドに API キーを置いてもよい場合はありますか

公開前提で発行されたキー（ドメイン制限付きの公開用キーなど）なら可能です。秘密鍵は置けません。ブラウザに渡る値は、誰でも見られます。

シークレットの検知ツールは何を選べばよいですか

まずは無料で使える gitleaks と、GitHub の Push Protection の併用がおすすめです。コミット前と push 時の二段で止められます。導入後は誤検知の扱いを決めておくと、続けやすくなります。

キーのローテーションはどのくらいの頻度で行えばよいですか

一律の正解はありません。発行元の推奨と、キーの権限の大きさで決めます。権限が大きいものほど短く、頻度の高い運用が向いています。まずは失効手順を整えることが先です。