Firebase の allow read, write: if true の解説: 何をするのか、どう修正するのか

構文を行ごとに

完全な Firestore テストモードルールドキュメントは 6 行です:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if true;
    }
  }
}

デコード:

• rules_version = '2'; は v2 ルールエンジン (現行) を選択します。古い v1 ルールは非推奨です。
• service cloud.firestore はブロックを Firestore にスコープします。Realtime Database は異なる JSON ベースの構文を使用し、Cloud Storage は service firebase.storage を使用します。
• match /databases/{database}/documents は特別な (default) データベースをバインドします (ほとんどのプロジェクトには 1 つしかありません)。
• match /{document=**} は再帰的ワイルドカードです。** は任意の深さの任意のパスに一致します。{document} と組み合わせて、すべてのコレクションのすべてのドキュメントをキャプチャします — データベース全体を支配する単一の match 句です。
• allow read, write: if true; はルール本体です。read と write の両方が許可され、条件 if true は、まあ、常に真です。read は get と list 操作をカバーし、write は create、update、delete をカバーします。

正味の効果: Firebase プロジェクト ID と適切な SDK を持つ任意のクライアントが、任意のコレクション内の任意のドキュメントを読み書きできます。認証は不要です。レート制限は強制されません。

なぜ Firebase はこれをデフォルトとして提供するのか

Firebase はプロジェクト作成後 30 秒以内にコーディングを始めてほしいのです。代替案 — 読み書きが機能する前に正しいルールを書かせること — はオンボーディングをブロックするでしょう。そこでコンソールは、データベースを作成する際に 2 つのオプションを提供します: 本番モード (すべて拒否、自分でルールを書く) または テストモード (30 日間すべて許可)。ほとんどの開発者はテストモードをクリックし、再訪を忘れます。古いプロジェクトには 30 日タイマーがありましたが、現在のプロジェクトは自動期限なしの無期限 if true ルールを持ちます。

構造的な問題: AI コーディングツールは、テストモードルールを示すドキュメント、チュートリアル、Stack Overflow の回答で訓練されます。Cursor や Claude Code に「Firebase をセットアップするには」と尋ねると、その答えにはしばしばまさに allow read, write: if true ブロックが本番ルールであるかのように含まれます。AI は知らないし、それを知るよう促されてもいません — このルールは本番には安全ではないということを。

攻撃者が見るもの

具体的には、あなたの Firebase プロジェクト ID (任意のデプロイされたアプリのバンドルから 30 秒で抽出可能) を知り、以下を実行する攻撃者は、すべてのコレクション内のすべてのドキュメントを列挙できます:

認証なしの単一の curl リクエストですべてのコレクションを列挙するのに十分です。下のハイライトされたブロックを参照してください。

curl 'https://firestore.googleapis.com/v1/projects/[project-id]/databases/(default)/documents:listCollectionIds' \
  -X POST \
  -H 'Content-Type: application/json' \
  -d '{}'

レスポンスはトップレベルコレクションの完全なリストです。各コレクションについて、2 回目のリクエストでドキュメントが返されます。このパスにレート制限はありません — if true ルールは匿名トラフィックを受け入れるからです。1 時間以内に数百万のドキュメントが列挙された Firebase データベースを見たことがあります。

書き込み経路では: {fields} を持つ単一の POST で新しいドキュメントが作成されます。攻撃者はあなたのコレクションをゴミで汚し、Firestore から読み取るユーザー向けページを改ざんし、または無料のメッセージブローカーとしてあなたのデータベースを使用できます — あなたの利用料が急騰し、調査すると、請求書が問題を説明します。

4 つの本番安全な置換

アプリのデータモデルに合う置換を選んでください。4 つすべてはユーザー認証 (Firebase Auth または Firebase ID トークンを発行する任意のプロバイダ) があることを前提とします:

オプション 1: ユーザー所有ドキュメント

最も一般的な SaaS パターン。ドキュメントは /users/{userId}/... 配下に存在し、所有者だけが触れられます。match /users/{userId}/{document=**} { allow read, write: if request.auth != null && request.auth.uid == userId; }

match /users/{userId}/{document=**} {
  allow read, write: if request.auth != null
                     && request.auth.uid == userId;
}

オプション 2: 各ドキュメントに所有者フィールド

ドキュメントがフラットなコレクションに (ユーザー ID 配下にネストされずに) ある場合、owner_uid フィールドを格納してチェックします。match /posts/{postId} { allow read: if resource.data.public == true || resource.data.owner_uid == request.auth.uid; allow write: if request.auth.uid == resource.data.owner_uid; }

match /posts/{postId} {
  allow read:  if resource.data.public == true
              || resource.data.owner_uid == request.auth.uid;
  allow write: if request.auth.uid == resource.data.owner_uid;
}

オプション 3: マルチテナント組織分離

組織スコープのデータを持つ B2B SaaS 向け。各ドキュメントに org_id フィールドを格納し、ユーザーのカスタムクレームと照合します。allow read, write: if request.auth.token.org_id == resource.data.org_id;。Firebase Admin SDK 経由でサインアップ時にカスタムクレームを設定する必要があります。

allow read, write: if request.auth.token.org_id == resource.data.org_id;

オプション 4: 読み取り専用の公開コンテンツ

マーケティングコンテンツ、公開プロフィール、製品カタログ向け — 真に公開読み取りで管理者のみ書き込み可能なもの。match /products/{productId} { allow read: if true; allow write: if request.auth.token.admin == true; }。admin カスタムクレームは管理者アカウントにのみ設定されます。

match /products/{productId} {
  allow read:  if true;
  allow write: if request.auth.token.admin == true;
}

クイック監査クエリ

修正前に、if true が実際に有効かを確認してください。Firebase コンソール → Firestore → Rules を開き、if true を検索します。コメント以外のどこかにそれを見つけたら、開いたルール検出があります。同じ UI のルールシミュレータでは、攻撃者のリクエストをローカルで再生できます — 匿名 GET /users/somebody を貼り付け、シミュレータが 許可 を返すことを確認します。

外部確認: 本番 URL に対して FixVibe スキャンを実行します。baas.firebase-rules チェックは、Firestore、Realtime Database、Storage ルールを探り、攻撃者が発見するのと同じ検出を — Firebase コンソールが何を表示するかとは独立して — 報告します。

よくある質問

次のステップ

本番 URL に対して FixVibe スキャンを実行してください — baas.firebase-rules チェックは if true が現在公開インターネットから悪用可能かを確認します。スキャナの仕組みと、Realtime Database と Storage の並列検出についてはFirebase ルールスキャナを参照してください。Supabase の同等クラスの設定ミスについてはSupabase RLS スキャナをお読みください。