「セキュリティは大事と聞くけど、何から手をつければ？」——そんな個人開発者のための、いちばん最初の一歩です。怖がらせるためでなく、今日から手を動かせることだけを、順番に説明します。
なぜ秘密の値（.envとAPIキー）から始めるのか
実際に起きる事故の多くは、高度な攻撃ではなく**「秘密の値が漏れた」**ことから始まります。当サイトが出発点にしている2つの事例も、どちらも秘密の漏洩でした：
つまり、秘密の値を守れれば、よくある事故の大半は防げます。だからここから始めます。
.env とは（30秒で）
.env（ドットエンブ）は、アプリが使う秘密の値をまとめた設定ファイルです。データベースのパスワード、外部サービスのAPIキー、セッションを暗号化する鍵などが入っています。1つのファイルに秘密の値が集まっているぶん、漏れると一気に全部漏れるので最優先で守ります（→ 用語：.env とは）。
秘密の置き場所の違い（.env・環境変数・シークレット管理）
.env 以外にも、秘密の値の置き場所はいくつかあります。規模と使う場面で選びます。
| 置き場所 | 向いている場面 | 注意点 |
|---|---|---|
.env ファイル | 手元での開発、1台だけの小さなサーバー | Gitに入れない。公開ディレクトリに置かない |
| ホスティングの環境変数設定（管理画面で入力するもの） | 本番環境 | 管理画面に入れる人を絞る。ビルドのログに値を出さない |
| CI（自動テスト・デプロイ）のシークレット | GitHub Actions などの自動処理 | CIで動く外部ツールにも値が見える。必要な権限だけのキーを渡す |
| シークレット管理サービス | 複数人・複数サーバーで使う場合 | 読める権限を最小にし、定期的に入れ替える |
CIのシークレットについては、2021年のCodecovの事件が参考になります。CIで実行していた外部ツールが改ざんされ、CIの環境変数に入っていた秘密が持ち出されました（→ Codecov 改ざん事件）。
公開してよいキーと、公開してはいけないキー
APIキーには、ブラウザやスマホアプリに入れる前提のものと、サーバーだけで使うものがあります。ブラウザに送ったものは誰でも読めると考えてください。
| 例 | 公開してよいか | 理由 |
|---|---|---|
Stripe の公開可能キー（pk_ で始まる） | よい | 公式文書で、フロントエンドに含めてよいとされている。決済の作成など重要な操作はできない |
Stripe のシークレットキー（sk_）・制限付きキー（rk_） | いけない | サーバー側の操作ができる。公式文書は、権限を絞った制限付きキーの利用をすすめている |
Next.js で NEXT_PUBLIC_ を付けた環境変数 | 公開される | ビルド時にブラウザ向けのJavaScriptへ値が埋め込まれる |
NEXT_PUBLIC_ を付けない環境変数 | 公開されない（サーバーだけ） | 秘密の値はこちらに置く |
迷ったら、そのサービスの公式文書で「クライアント側で使ってよいか」を確認します。書いていなければ、公開してはいけないキーとして扱います。
APIキーが漏れると何が起きるか
APIキーは「あなたとして外部サービスを使うための認証用の文字列」です。これが他人の手に渡ると、次のように被害が広がります。
盗まれたキーは時間差で売買・悪用されることが多く、「漏れた直後は何も起きない→後日いきなり請求」というパターンが典型です。だから「気づいてから」では遅く、最初から漏らさないことが肝心です。
漏れたかもしれないときの手順
キーを消すだけでは止まりません。セキュリティ企業GitGuardianの2025年の報告では、2022年に公開リポジトリで漏れた秘密の70%が、報告の時点でまだ使える状態でした。次の順番で対応します。
- 発行元の管理画面でキーを失効させるか、入れ替える（ローテーション）。猶予期間を選べるサービスでは、漏れたキーは「今すぐ」無効にする
- 新しいキーを本番環境に設定し、アプリが動くことを確かめる
- 発行元の利用履歴と請求を見て、自分以外の利用がないか確認する
- ファイルやGitの履歴から消すのは、失効させた後でよい（消すだけでは、すでに写しを持つ人は使える）
詳しい事例は GitHubに公開された認証情報54万件が今も有効 にまとめています。GitHubには、個人アカウントが公開リポジトリへ秘密をプッシュしようとすると止める「プッシュ保護」が既定で入っていますが、すべての種類の秘密を止めるわけではありません。
今日からできる4つの守り方
むずかしいことは要りません。まずこの4つだけ。
公開しない
.env やアプリ本体を、Webで見えるディレクトリ（公開ルート）に置かない。公開するのは public/ だけ。レンタルサーバーでの具体手順は この記事。
コミットしない
.gitignore に .env* を入れる（!.env.example は許可）。値の入っていない見本だけ共有。一度コミットすると履歴から復元できるので最初から入れない。
漏れたら全部替える
1個だけでなく、漏れた可能性のあるキーやパスワードを全部ローテーション。優先順は「外部API・OAuth → 暗号鍵 → メール → DB」。見られた前提で動く。
自己点検する
自分のサイトで /.env が外から開けないか、ときどき確認する（下記）。
自己点検（自分の所有ドメインにだけ）
# 200 で本文が返ったら公開されている。403/404 なら一旦OK
curl -sI https://あなたのドメイン/.env | head -1
curl -sI https://あなたのドメイン/.git/config | head -1公開のたびにこれを確認する癖をつけると、配置ミスを早期に発見できます。
サイトの外から見えるかに加えて、Gitとビルド結果も確認します（自分のリポジトリで実行）。
# .env が過去に一度でもコミットされたか（何か表示されたら、入っていた時期がある）
git log --all --oneline -- .env
# いまGitの管理下にある env 系のファイル（.env.example 以外が出たら要確認）
git ls-files | grep -i "env"ブラウザに配るファイルにキーが入っていないかは、ビルド結果のフォルダ（Next.js なら .next/static）をキーの先頭数文字で検索して確かめます。公開前のコードは シークレット漏れ検出 に貼って調べることもできます（内容は送信されません）。
やりがちな失敗 vs 正しい一歩
やりがち
- とりあえず動いたから
.envを public 直下に置く - 「あとで消すから」と
.envを一度gitに入れる - 悪用が見えた1個のキーだけ替える
正しい一歩
- 本体は公開ルートの外、
public/だけ公開 - 最初から
.gitignoreで.envを除外 - 漏れたら env のキーやパスワードを全部ローテーション
次のステップ
ここまで来たら、次は「自分のスタックの危ない初期設定」と「公開済みの脆弱性（CVE）に後れを取らないしくみ」です。焦らず1つずつ。
出典
- Next.js「How to use environment variables in Next.js」（16.x） — nextjs.org
- Stripe Docs「API キー」 — docs.stripe.com
- Laravel 13.x「Configuration」（Environment File Security） — laravel.com
- GitHub Docs「About push protection」 — docs.github.com
- GitGuardian「The State of Secrets Sprawl 2025」 — blog.gitguardian.com
次に読む
- 漏らした後の対応：GitHubに公開された認証情報54万件が今も有効——削除ではなく失効が必要な理由
- Gyazoの情報漏えい（2026年9月）：Gyazoの不正アクセス（約2,362万件）：ユーザー情報と画像のメタデータが流出、利用者が今日やること
- 用語：.env とは / CVE とは / RCE とは
- 対策：レンタルサーバーで .env を公開しない / Next.js のCVE追従
- 事故：APIキーが盗まれて不正課金された話
- 事故：盗まれたキーでアカウントが凍結された話
- サプライチェーン攻撃：npm install だけで認証情報が抜かれる（キーが保存されている環境で、他人のコードが動く話）
よくある質問
Qセキュリティの勉強、何から始めればいい？
まず『秘密の値（.env と APIキー）を漏らさない』ことから。多くの実際の事故はここから起きています。公開しない・gitにコミットしない・漏れたら全部入れ替える・たまに自己点検する、の4つで大半を防げます。
QAPIキーが漏れると具体的に何が起きる？
他人があなたになりすまして外部サービスを使えます。よくあるのが不正課金（あなたの請求で大量利用される）や、データの読み書きです。漏れたキーは時間差で売買・悪用されることも多いです。
Q.env はgitに入れていい？
いけません。.gitignore に .env* を入れ、値を空にした .env.example だけを共有します。一度コミットすると、後で消しても git の履歴から復元できてしまいます。
Q.env とは何ですか？
アプリが使う設定値、特にパスワードやAPIキーのような秘密の値を、コードとは別にまとめておくテキストファイルです。「名前=値」の形で1行に1つずつ書きます。Laravel・Next.js・Djangoなど多くのフレームワークが起動時に読み込みます。秘密がまとまっているので、Gitに入れない・公開ディレクトリに置かないことが前提です。
Q.env と環境変数は何が違うのですか？
環境変数は、OSや実行環境がプログラムに渡す設定値のしくみそのものです。.env はその値をファイルに書いておき、アプリやライブラリが起動時に読み込んで環境変数として使えるようにするための入れ物です。本番では .env ファイルを置かず、ホスティングの管理画面やシークレット管理サービスから環境変数として渡す方法もよく使われます。
QAPIキーをフロントエンド（ブラウザ側）のコードに書いても大丈夫ですか？
公開してよいと明記されたキー以外はいけません。ブラウザに送ったJavaScriptは誰でも読めます。たとえばStripeでは、公開可能キー（pk_ で始まる）はフロントエンドに含めてよい一方、シークレットキー（sk_）や制限付きキー（rk_）は公開してはいけないと公式文書に書かれています。Next.jsでは NEXT_PUBLIC_ を付けた環境変数がブラウザ向けのコードに埋め込まれるので、秘密の値には付けません。