フロントエンドとAPIの.envファイル運用とセキュリティの考え方
Webアプリ開発では、環境変数（.env）の扱いを誤ると重大な情報漏洩につながります。
この記事では、フロントエンドとAPIそれぞれの.envの役割と、安全な運用方法を整理します。
① そもそも.envファイルとは？
.envファイルは、アプリの設定値（環境変数）を管理する仕組みです。
例：
DATABASE_URL=postgres://xxx
API_URL=https://api.example.com
② フロントエンドとAPIでの決定的な違い
まず一番重要な前提です👇
👉 フロントの.envは「公開される前提」
👉 APIの.envは「絶対に外に出してはいけない」
③ フロントエンドの.env（公開情報）
フロントエンド（React / Next.jsなど）の.envは、ビルド時にJSへ埋め込まれます。
つまり：
👉 ブラウザから誰でも見える
フロントで扱ってよいもの
- APIのURL
- 公開前提のID（例：Cognito Client ID）
- フラグ（feature flagなど）
例：
NEXT_PUBLIC_API_URL=https://api.example.com
NEXT_PUBLIC_COGNITO_CLIENT_ID=xxxx
フロントで絶対NGなもの
- DB接続情報
- APIシークレットキー
- JWT秘密鍵
- AWSシークレットキー
👉 これを入れた瞬間に漏洩確定です
④ API（バックエンド）の.env（秘密情報）
API側（Node.js / NestJSなど）の.envはサーバー内でのみ使われます。
👉 外部から直接見えない
👉 だから秘密情報を持てる
APIで扱うもの
DATABASE_URL=postgres://xxx
JWT_SECRET=super-secret
AWS_SECRET_ACCESS_KEY=xxxx
セキュリティの本質
APIは「秘密を守る壁」です。
フロント：
👉 ユーザーの手元（信用できない）
API：
👉 サーバー内（信用できる）
⑤ よくある勘違い（かなり重要）
❌ Client IDは秘密？
結論👇
👉 秘密ではない（フロントに置いてOK）
例えば Amazon Cognito の Client ID は公開前提です。
理由：
- それ単体では認証できない
- 実際の認証はリダイレクトやトークンで行う
❌ APIキーは全部秘密？
👉 サービスによる
- 公開用キー（例：Google Maps） → OK
- サーバー用キー → NG
⑥ よくある事故パターン
① フロントに秘密を書く
NEXT_PUBLIC_API_SECRET=xxxx ←アウト
② Gitにコミット
.env ← pushしてしまう
③ ログに出す
console.log(process.env.JWT_SECRET)
⑦ 安全な運用ルール
① .envはGit管理しない
.env
.env.local
👉 .gitignore に追加
② サンプルファイルを用意
.env.example
DATABASE_URL=
JWT_SECRET=
③ 環境ごとに分ける
.env.development
.env.staging
.env.production
④ 本番は.envを使わない（理想）
本番では：
- AWS Parameter Store
- Secrets Manager
- CI/CD環境変数
などを使う
⑧ フロントとAPIの責務分離（重要）
設計としてはこうなります👇
[フロント]
↓（公開情報のみ）
[API]
↓（秘密情報使用）
[DB / 外部サービス]
具体例
フロント
fetch('/api/user')
API
const user = db.find(...)
👉 DB情報はフロントに一切渡らない
⑨ 実務での判断基準
迷ったらこれ👇
👉 「その値をブラウザで見られて困るか？」
- YES → API側に置く
- NO → フロントでもOK
まとめ
| 項目 | フロント | API |
|---|---|---|
| 公開されるか | される | されない |
| 秘密情報 | ❌ NG | ✅ OK |
| 役割 | 表示・操作 | 認証・データ管理 |
補足
.envの扱いのコツ
- フロントは信用しない
- APIに責務を寄せる
- 秘密はサーバーに閉じる