なぜ危ないのか
FirebaseのapiKeyはGoogleのサービスを識別するためのキーであり、Firebaseのセキュリティルールが正しく設定されていれば公開しても問題ないとGoogleは説明している。しかし多くのAI生成HTMLはFirebaseのセキュリティルールの存在を考慮せず実装されるため、ルールが `allow read, write: if true;` のような全許可状態になっているリスクがある。この状態でapiKeyが露出すると、Firestoreのデータを誰でも読み書きできてしまう。
より注意すべきなのは、AIがFirebase Admin SDKのような用途に使うサービスアカウントキー（JSONファイル）の中身をHTMLに直接貼り付けるケースだ。`private_key`フィールドを含むサービスアカウントJSONはFirebaseのセキュリティルールを完全に迂回できるため、絶対にHTMLに含めてはならない。クライアント設定のapiKeyとサービスアカウントのprivate_keyは全く性質が異なるが、AIはその区別をしないことがある。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
ソースで見る場所
HTMLを開いて `firebaseConfig` を検索すると、設定オブジェクトがまとめて確認できる。apiKey・authDomain・projectId・storageBucket・messagingSenderId・appIdの6項目が並んでいれば、それがFirebaseのクライアント設定だ。この設定自体はFirebaseのセキュリティルールを適切に設定してあれば公開可能だが、セキュリティルールの設定状況を必ずFirebaseコンソールで確認すること。
`private_key` や `client_email` というキー名を検索し、これらが含まれているかも確認する。もしヒットした場合、それはサービスアカウントの認証情報であり、絶対に共有してはならない。`BEGIN PRIVATE KEY-----` という文字列がHTMLに含まれていれば、サービスアカウントのprivate keyがそのまま埋め込まれている状態だ。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
安全に共有する設定
Firebaseクライアント設定（apiKeyなど6項目）のみが含まれており、かつFirebaseコンソールでセキュリティルールが適切に設定（認証済みユーザーのみ許可など）されていれば、HTMLの共有は許容できる範囲内だ。ただし不特定多数に公開するのではなく、認証付きのリンクで特定のレビュアーだけに共有することを推奨する。
サービスアカウントキーや`private_key`が含まれていた場合は、共有前に必ずその行を削除またはプレースホルダに置換する。Firebaseコンソールの「プロジェクトの設定」→「サービスアカウント」からそのキーを削除（無効化）し、新しいキーを再発行する。漏えいが起きた可能性がある場合はFirebaseのセキュリティルールを一時的に全拒否に変更して影響を最小化する。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
再発防止ルール
AIへのプロンプトに「Firebase設定はconfigオブジェクトのプレースホルダのみ記述し、実際のapiKeyやprojectIdを文字列として書かないこと。サービスアカウントキーは絶対に使用しないこと。」と明示する。これによりAIは `const firebaseConfig = { apiKey: 'YOUR_API_KEY', ... }` の形式で出力するようになる。
Firebaseコンソールのセキュリティルールを定期的にレビューするサイクルをチームに組み込む。AI生成コードをデプロイする前に、Firebaseのセキュリティルールシミュレーターで想定外のアクセスが許可されていないかテストする手順を標準化する。特に `if true` や `if request.auth != null` だけのシンプルなルールは実態に即しているか確認が必要だ。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
よくある質問
Firebase apiKeyが漏えいしても、セキュリティルールが適切なら本当に安全ですか？
Googleの公式見解ではセキュリティルールが正しければapiKeyの露出は許容されるとしているが、ルール設定の見落としリスクを考慮すると、不必要に公開する状況は避けた方がよい。特にFirebase Authが絡む設定では、ルールの組み合わせが複雑になるため専門家レビューを推奨する。
サービスアカウントキーをHTMLに入れてしまいました。最初にすることは何ですか？
Firebaseコンソールの「プロジェクトの設定」→「サービスアカウント」でそのキーを即座に削除する。削除後はFirebaseのルールを全拒否に設定し、アクセスログを確認して不正利用の痕跡がないか調べる。その後、影響範囲を確認してステークホルダーへ報告する。
Firebase Hosting用のHTMLであれば、設定を含めても問題ありませんか？
Firebase Hostingは全世界に公開されるため、設定値もすべて公開される。apiKey等のクライアント設定はセキュリティルール前提で許容されるが、サービスアカウントキーはHostingのHTMLには絶対に含めてはならない。Hostingにデプロイする前に必ず `private_key` の有無を確認する。