.ENVインスペクター — 無料オンラインツール

.envファイルを貼り付けて、フォーマットの検証、公開されたAPIキーやシークレットの検出、安全な.env.exampleの生成が可能です。すべての処理は100%クライアントサイドで実行されます。

シークレットはローカルに保持：このツールはブラウザ内で完全に動作します。ネットワークリクエストは一切発生しません。DevToolsのNetworkタブで確認できます。
🔍

上に.envファイルを貼り付けてください

シークレットの検出、フォーマットの検証、.env.exampleの生成を行います

.ENVインスペクターの検査内容

.ENVインスペクターは、環境変数ファイルを3つのカテゴリで分析します：シークレットの公開リスク、フォーマットの問題、完全性。各行を解析し、変数を機密度で分類し、チーム向けの安全なテンプレートファイルの生成を支援します。

シークレットパターンの検出

インスペクターは、一般的な機密クレデンシャルのパターンに一致する変数名にフラグを立てます。キーに以下のパターンが含まれる場合、変数はシークレットとして分類されます：

  • API クレデンシャル：API_KEY、API_SECRET、API_TOKEN、ACCESS_KEY、ACCESS_TOKEN
  • 認証：PASSWORD、PASSWD、PWD、AUTH、BEARER、OAUTH、SESSION_SECRET
  • 暗号化：PRIVATE_KEY、SECRET、HMAC、SALT、SIGNING_KEY、ENCRYPTION_KEY
  • データベース：DATABASE_URL、DB_URL、MONGO_URI、POSTGRES_URL、MYSQL_URL、CONNECTION_STRING、DSN
  • インフラストラクチャ：WEBHOOK_SECRET、CERTIFICATE、CREDENTIAL、REDIS_PASSWORD

よくある.envフォーマットの問題

  • イコール記号の欠落：すべての変数はKEY=VALUEパターンに従う必要があります。=のない行は無効です。
  • 無効なキー名：キーには大文字、数字、アンダースコアのみを使用してください。数字で始まるキーやスペースを含むキーは、ほとんどの環境で無効です。
  • 引用符で囲まれていないスペースを含む値：スペースを含む値は引用符で囲む必要があります：APP_NAME="My Application"
  • インラインコメント：一部のパーサーはインラインコメント（PORT=3000 # web port）をサポートしていません。コメントは独立した行に記述してください。
  • 末尾のスペース：値の末尾の空白は、特にパスワードやトークンで微妙なバグを引き起こす可能性があります。

.envセキュリティのベストプラクティス

  • 必ず.envを.gitignoreに追加：最初のコミットの前にecho ".env" >> .gitignoreを実行してください。一度git履歴にシークレットが記録されると、漏洩したものとして扱う必要があります。ローテーションが唯一の対処法です。
  • 代わりに.env.exampleをコミット：実際の値を公開せずに、必要な変数を文書化します。新しいチームメンバーはこのファイルをコピーして、自分のシークレットを入力できます。
  • 環境ごとに異なるクレデンシャルを使用：本番、ステージング、開発環境にはそれぞれ別のAPIキーとデータベースクレデンシャルを使用してください。本番のシークレットを開発環境で再利用しないでください。
  • シークレットを定期的にローテーション：シークレットはパスワードと同様に扱い、定期的にローテーションし、アクセス権を持つ人がチームを離れた場合は直ちにローテーションしてください。
  • 本番環境ではシークレットマネージャーを使用：本番ワークロードでは、ディスク上の.envファイルよりもAWS Secrets Manager、HashiCorp Vault、Dopplerなどの専用シークレット管理ソリューションを使用することを推奨します。
  • 環境変数をログに記録しない：特に本番環境ではprocess.envをログに出力しないでください。機密パターンを除去するログフィルタリングを設定してください。

現代の開発における環境変数のセキュリティ

環境変数は、機密情報をハードコーディングせずにアプリケーションを設定する標準的な方法です。しかし、環境変数の管理ミスはセキュリティ侵害の最も一般的な原因の一つです。適切な.envファイルの扱いを理解することは、すべての開発チームにとって重要です。

.envファイルのライフサイクル：開発から本番まで

  • 開発： ダミーまたはローカルの値を持つ.envファイルを使用します。必要なすべてのキー（ただし実際の値は含まない）を含む.env.exampleファイルをコミットし、新しいチームメンバーが何を設定すべきかわかるようにします。
  • CI/CD： シークレットをリポジトリに保存しないでください。CIプラットフォームのシークレット管理（GitHub Actions Secrets、GitLab CI Variables、CircleCI Contexts）を使用して、ビルド時に環境変数を注入します。
  • ステージング/本番： AWS Secrets Manager、HashiCorp Vault、Google Secret Manager、Dopplerなどの専用シークレットマネージャーを使用します。これらは監査ログ、自動ローテーション、アクセス制御を提供します。

よくある.envセキュリティの間違い

  • .envをGitにコミット： ファイルを後で削除しても、Git履歴に永久に残ります。これが起こった場合、露出したすべてのシークレットを直ちにローテーションし、git filter-branchまたはBFG Repo-Cleanerを使用して履歴からファイルを削除します。
  • 環境変数のログ出力： 環境全体をログに記録しないでください（console.log(process.env)やprint(os.environ)）。これによりすべてのシークレットがログ集約ツールに出力され、権限のないチームメンバーがアクセスできる可能性があります。
  • チャット/メールでの共有： Slack、メール、その他のメッセージングプラットフォームでシークレットを共有しないでください。シークレットマネージャーの共有機能や、Dopplerや1Passwordのセキュアシェアリングなどのワンタイムシークレット共有ツールを使用してください。
  • フロントエンドコードでのシークレット使用： NEXT_PUBLIC_、VITE_、REACT_APP_の接頭辞が付いた環境変数は、クライアント側のバンドルに埋め込まれ、誰でも見ることができます。APIキー、データベース認証情報、認証シークレットをフロントエンドの環境変数に入れないでください。

シークレットの検出と防止

開発ワークフローでシークレット検出を自動化し、本番環境に到達する前に漏洩を検出します。git-secrets、truffleHog、detect-secretsなどのツールは、APIキー、パスワード、トークンに一致するパターンをコミットからスキャンできます。GitHubはパブリックリポジトリに対して組み込みのシークレットスキャンも提供しており、コード内で既知のシークレット形式が検出された場合にアラートを送信します。

.envファイルに関するよくある質問

このツールに.envファイルを貼り付けても安全ですか？

はい — このツールはブラウザ内で完全に動作します。サーバーへのデータ送信は一切行われません。ブラウザのDevTools → Networkタブを開いて確認できます。送信リクエストがゼロであることが確認できます。分析はJavaScriptでローカルに行われ、タブを閉じると消去されます。

.envファイルとは何ですか？どのように機能しますか？

.env（dotenv）ファイルは、アプリケーションの環境変数を格納するプレーンテキストファイルです。変数は1行に1つずつKEY=VALUE形式で記述します。dotenv（Node.js）、python-decouple（Python）、godotenv（Go）などのライブラリが起動時にこれらのファイルを読み込み、プロセスの環境変数として利用可能にします。これにより設定とコードが分離され、同じコードベースが異なる.envファイルで開発、ステージング、本番環境で動作します。

.env、.env.local、.env.productionの違いは何ですか？

多くのフレームワーク（Next.js、Vite、Create React App）は、異なる読み込み優先順位を持つ複数の.envファイルバリアントをサポートしています。.envはすべての環境で読み込まれるデフォルトです。.env.localは.envを上書きし、gitで無視されます。.env.productionと.env.developmentは環境固有です。.env.localは常に環境固有のファイルよりも優先されます。正確な読み込み順序についてはフレームワークのドキュメントを確認してください。

.envファイルを誤ってGitにコミットしてしまいました。どうすればよいですか？

直ちに公開されたすべてのクレデンシャルをローテーションしてください。git履歴は削除後も永続的であるため、漏洩したものとして扱う必要があります。git rm --cached .envでファイルを削除し、.envを.gitignoreに追加し、git filter-branchまたはBFG Repo Cleanerで履歴を上書きするために強制プッシュしてください。リポジトリが公開されているか、クローンされている場合は、履歴の書き換えに関係なく、すべてのシークレットが漏洩したものとみなしてください。

関連する開発者ツール