なぜ危ないのか
Firebase設定にはレベルが異なる2種類が存在する。一つはwebアプリ向けのクライアント設定（apiKey・projectId等）で、これはFirebaseのセキュリティルールに基づいてアクセスが制御される。もう一つはサーバー向けのサービスアカウントキー（`private_key`を含むJSON）で、セキュリティルールを完全に迂回できる。AIはこの区別をしないまま両方をHTMLに埋め込むことがあり、特にサービスアカウントキーの混入は重大なインシデントにつながる。
クライアント設定のapiKeyが漏えいした場合、Firestoreのセキュリティルールが `allow read, write: if true;` であれば全データへのアクセスが可能になる。このルールはAI生成のプロトタイプに多く、「まず動かす」目的で設定されることが多い。本番データが入ったFirestoreプロジェクトのapiKeyを、ルール未設定のままHTMLに含めて共有するのが最も危険なパターンだ。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
ソースで見る場所
HTMLの `<script>` タグ内を中心に `firebaseConfig` を検索し、含まれているキー名を確認する。apiKey・authDomain・projectId・storageBucket・messagingSenderId・appIdの6項目はクライアント設定であり、適切なセキュリティルールのもとでは公開可能な範囲だ。一方、`type: 'service_account'`・`private_key`・`client_email` が含まれていれば、それはサービスアカウントキーであり緊急対処が必要だ。
`BEGIN PRIVATE KEY-----` という文字列を検索するのも有効だ。PEM形式の秘密鍵がHTMLに含まれていれば、即座に共有を中止してFirebaseコンソールでキーを無効化する。この検索はワンライナーで実行できるため、共有前の最低限チェックとして習慣化するとよい。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
安全に共有する設定
サービスアカウントキーが含まれていないことを確認できたら、次はFirebaseコンソールでセキュリティルールを確認する。Firestore・Storage・Realtime Databaseそれぞれのルールで `allow read, write: if true;` になっているものがあれば、共有前にルールを修正するかapiKeyをプレースホルダに置換する。本番データが入ったプロジェクトのHTMLを共有する際は、認証付きのリンクを使い閲覧者を限定する。
デモ専用のHTMLを共有する場合は、本番Firebaseプロジェクトとは別にテスト用のプロジェクトを作成し、ダミーデータのみを入れてセキュリティルールも緩く設定した上でそのapiKeyだけを埋め込む。レビュー終了後はテストプロジェクトを削除してキーを消去することで、本番への影響なくデモHTMLの運用ができる。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
再発防止ルール
Firebase設定を含むHTMLをAI生成する際は「サービスアカウントキーは使用せずクライアント設定のみ使うこと。apiKeyは`YOUR_FIREBASE_API_KEY`というプレースホルダで記述すること」とプロンプトに明示する。サービスアカウントキーの使用を制約することで、最も危険なパターンを生成段階で排除できる。
公開・共有フローにFirebaseコンソールのセキュリティルール確認ステップを追加する。「Firestore→ルール→`if true`がないことを確認」という一項目を共有前チェックリストに組み込み、デプロイや送信の前に必ず確認する運用を徹底する。ルールの設定変更はコードとセットでGitに記録し、いつ・誰が変更したかを追跡できる状態にしておく。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
よくある質問
Firebaseのapiキーを誤って共有してしまった後、すぐにキーをローテーションすべきですか？
Firebaseのクライアント用apiKeyはGoogleのAPIキー管理画面からローテーションできるが、影響範囲が広い。まずセキュリティルールを確認・修正し、ルールで保護できる状態にすることが先決だ。サービスアカウントキーを共有した場合はただちにFirebaseコンソールから削除する。
Firebaseセキュリティルールを適切に設定するにはどうすればよいですか？
Firebaseコンソールの「Firestore Database」→「ルール」でルールを確認・編集できる。基本は `allow read, write: if request.auth != null;`（認証済みユーザーのみ許可）から始め、必要に応じてフィールド単位の条件を追加する。シミュレーターで想定するアクセスパターンをテストしてから公開することを推奨する。
Firebase HostingでHTMLを公開する場合、セキュリティルールは特に重要ですか？
Firebase Hostingは全世界に公開されるためapiKeyが誰でも確認できる状態になる。セキュリティルールが最後の防御ラインとなるため、デプロイ前にFirestore・Storage・Realtime Databaseのすべてのルールを確認し、全許可になっているものがないかチェックすることが不可欠だ。