.env はとても便利で、ほぼ全てのモダンなフレームワークが使います。でも置き場所を一つ間違えると、サイトの秘密の値がすべて誰でも読める状態になります。意味と守り方をゼロから解説します。
もう少し詳しく
アプリには「環境ごとに変わる値」や「人に見せたくない値」があります。DBのパスワード、外部サービスのAPIキー、セッションを暗号化する鍵など。これらをソースコードに直書きすると、コードを共有した瞬間に秘密も一緒に漏れます。
そこで、これらを .env という1つのファイルに集め、コードからは「環境変数」として読み込みます。Next.js・Laravel・Rails など多くのフレームワークがこの方式です。
中身は「名前=値」を1行ずつ並べただけのテキストです(値は説明用のダミー)。
APP_ENV=production
DB_HOST=127.0.0.1
DB_PASSWORD=ここにDBのパスワード
PAYMENT_API_KEY=ここに決済サービスのAPIキー設定をコードの外に出す考え方は、Webアプリの設計指針「The Twelve-Factor App」が広めたものです。この指針は、いつでもコードをオープンソースにできるか、つまり公開しても認証情報が漏れないかを、設定を正しく分けられているかの目安にしています。.env は、この考え方を開発しやすくするための入れ物です。
似たものとの違い
.env と混同されやすいものを並べます。秘密の値を置いてよい場所は限られます。
| 名前 | 何か | 秘密を置いてよいか |
|---|---|---|
| 環境変数 | OSやコンテナが実行中のプロセスに渡す値 | よい(本番ではこちらが基本) |
.env | 環境変数をファイルにまとめたもの | よい。ただし公開場所とGitには置かない |
.env.example | 必要な名前だけを並べ、値を空にした見本 | 置かない(Gitにコミットする前提) |
NEXT_PUBLIC_*・VITE_* | ブラウザ用のJavaScriptに埋め込まれる変数 | 置かない(誰でも読める) |
| シークレット管理サービス | クラウドが提供する、秘密の値の保管庫 | よい。権限と監査ログで管理できる |
見落としやすいのは4行目です。Next.js は NEXT_PUBLIC_ で始まる変数の値を、Vite は VITE_ で始まる変数の値を、ビルド時にブラウザへ配るJavaScriptへ埋め込みます。.env に書いてあっても、名前にこの接頭辞が付いた時点で公開情報になります。
なぜ「最も危険なファイル」なのか
.env は1ファイルに複数の鍵がまとまっているため、ここが漏れると被害が一気に広がります。鍵ごとに「漏れると何が起きるか」を並べると、深刻さが分かります。
| 漏れた値 | 何が起きるか |
|---|---|
| DB認証情報 | データの読み出し・改ざん・全削除 |
| 外部APIキー | なりすまし利用・不正課金 |
暗号鍵(例 Laravel APP_KEY・署名鍵) | セッション偽造・なりすましログイン |
| OAuthシークレット | 連携アプリの乗っ取り |
実際、.env の公開は事故の定番です。→ .env が全世界に公開されていた話
具体例:公開された .env が狙われた事例
- 大規模な恐喝の手口(2024年):あるセキュリティ企業の調査部門は、11万のドメインを対象に、Webサーバーで公開されていた
.envを集めて中のクラウドの認証情報を使い、データを持ち出して身代金を要求する活動を報告した。集められた変数は9万件を超え、うち約7,000件がクラウドサービス、約1,500件がSNSアカウントのものだった。原因はクラウド側の脆弱性ではなく、.envを公開していた側の設定ミスとされている - Vercel(2026年4月):社内システムへの不正アクセスにより、一部の顧客の、値を画面に表示できる区分で保存されていた環境変数が読み出された → 詳しい解説
- 公開リポジトリ(2026年の調査):GitHubに公開された認証情報のうち54万件余りが、調査時点でまだ有効だった。ファイルや履歴を消しても、失効させない限り使える → 詳しい解説
1つ目の事例が示すのは、公開された .env は人が見つけるのではなく、自動で大量に集められるということです。小さなサイトだから見つからない、とは考えないでください。
漏れる典型パターン=置き場所のミス
最大の原因は「アプリ本体を公開ディレクトリ(docroot)に丸ごと置く」ことです。public/ だけを見せるべきところで、その親を公開すると .env まで取れてしまいます。
✗ 危険(本体を公開ルート直下)
public_html/ ├─ .env ← 読める! ├─ app/ └─ public/
✓ 安全(本体は外、public だけ公開)
app-root/ ├─ .env ← 到達不能 ├─ app/ └─ public_html/ → public/
置き場所のほかに、次の経路でも漏れます。
- Gitにコミットしてしまう(公開リポジトリなら即座に、非公開でも権限のある人全員に見える)
.env.bakや.env.oldなどのバックアップを公開ディレクトリに残す- コンテナイメージや配布用のzipに
.envが入ったまま公開する - 上で説明した
NEXT_PUBLIC_・VITE_付きの変数に秘密を入れる
守り方
公開ディレクトリに置かない
アプリ本体は docroot の外、公開するのは public/ 等だけ。レンタルサーバーでの具体手順は この記事。
gitにコミットしない
.gitignore に .env* を入れ、値を空にした .env.example だけ共有する。
漏れたら全部ローテーション
確認できた1個でなく、.env にあった鍵を全部入れ替える。見られた前提で動く。
定期的に自己点検
自分のサイトで /.env が開けないか確認する習慣を。
自分のサイト・リポジトリで確認する方法
自己点検(自分の所有ドメインにだけ)
# 200 で本文が返ったら公開されている。403/404 なら一旦OK
curl -sI https://あなたのドメイン/.env | head -1
curl -sI https://あなたのドメイン/.git/config | head -1公開のたびにこれを確認する癖をつけると、配置ミスを早期に発見できます。
サイトの外側と、リポジトリの中の両方を確かめます。
- 所有を確認したサイトなら、サイト総合セキュリティ診断で
/.env・/.env.local・/.env.bakなどの公開をまとめて点検できる - リポジトリで
git log --all --oneline -- .envを実行し、過去に一度でもコミットされていないか確かめる。何か表示されたら、中の鍵を失効させる - 設定ファイルやコードの一部をシークレット漏れ検出に貼り、APIキーや秘密鍵が直書きされていないかを見る(ブラウザ内で処理)
- ビルドしたJavaScriptに秘密の値が含まれていないか、
NEXT_PUBLIC_・VITE_付きの変数の一覧を見直す
当サイトの視点:.env は『置き場所』と『失効の手順』をセットで決める
.env の事故の多くは、ファイル1つの置き場所の誤りから始まります。そして漏れた後に被害を広げるのは、鍵を入れ替える手順が決まっていないことです。当サイトは、.env を使うなら「公開ディレクトリの外に置く」「Gitに入れない」に加えて、「中の鍵それぞれの失効・再発行の手順」を先に書いておくことを勧めています。本番では、クラウドのシークレット管理サービスや、値を後から表示できない区分の環境変数に移すと、漏れる経路をさらに減らせます。
出典(一次情報)
- The Twelve-Factor App「III. Config」 — 12factor.net(設定を環境変数に置く、オープンソースにできるかという目安)
- Next.js ドキュメント「Environment Variables」 — nextjs.org(
NEXT_PUBLIC_はビルド時にJavaScriptへ埋め込まれる、.env をコミットしない) - Vite ドキュメント「環境変数とモード」 — vite.dev(
VITE_付きの変数はクライアントに公開される) - Unit 42(Palo Alto Networks)「Leaked Environment Variables Allow Large-Scale Extortion Operation in Cloud Environments」(2024年8月15日) — unit42.paloaltonetworks.com
次に読む
分類番号
CWE は脆弱性の原因となる弱点の種類を、MITRE ATT&CK は攻撃者の手口を分類した番号体系です。どちらも MITRE が管理し、脆弱性情報や検知ルールの分類に広く使われています。
CWE™: Copyright © 2006–2026, The MITRE Corporation. CWE is a trademark of The MITRE Corporation. The MITRE Corporation hereby grants you a non-exclusive, royalty-free license to use CWE for research, development, and commercial purposes. Any copy you make for such purposes is authorized on the condition that you reproduce MITRE’s copyright designation and this license in any such copy. CWE Terms of Use
よくある質問
Q.env はgitにコミットしていい?
いけません。.gitignore に必ず .env を加えます。代わりに、値を空にした .env.example だけをコミットして『どんなキーが必要か』を共有します。
Q.env が1個でも漏れたら、何を入れ替える?
確認できた1個だけでなく、.env に入っていた鍵を全部ローテーションします。優先順は『外部API・OAuthシークレット → 暗号鍵 → メール → DB』。見られた前提で動くのが安全です。
Q.env が漏れたか、どう確認する?
自分のサイトで https://あなたのドメイン/.env をブラウザで開いてみて、中身が表示されたら公開されています(200で本文が見えたら公開状態)。表示されず 403/404 ならひとまずOKです。
Q.env の読み方と意味は?
「ドットエンブ」や「ドットイーエヌブイ」と読みます。env は environment(環境)の略で、先頭のドットはLinuxやmacOSで隠しファイルを表す印です。中身は「DB_PASSWORD=…」のような『名前=値』の行の並びで、アプリはこれを環境変数として読み込みます。
QNEXT_PUBLIC_ や VITE_ で始まる変数に秘密を入れていい?
いけません。Next.js の NEXT_PUBLIC_、Vite の VITE_ で始まる変数は、ビルド時にブラウザへ配るJavaScriptに値が埋め込まれ、誰でも読めます。.env に書いてあっても秘密にはなりません。APIキーなどはサーバー側の処理だけで使い、名前にこれらの接頭辞を付けないようにします。
Q.env を誤ってGitHubにpushしてしまったら?
まず、中にあった鍵をすべて失効・再発行します。ファイルを消したり履歴を書き換えたりしても、すでに複製された可能性は消せないので、削除より失効が先です。そのうえで .gitignore に .env を加え、履歴からも取り除きます。