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 は知らないし、それを知るよう促されてもいません — このルールは本番には安全ではないということを。

攻撃者が見るもの

Concretely, an attacker who knows your Firebase project ID (it ships in every deployed app's configuration) can list every collection and read every document with plain, unauthenticated requests to Firebase's public REST API.

Once the collections are listed, every document in them can be read. Nothing slows this down, because if true rules accept anonymous traffic.

書き込み経路では: {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 を貼り付け、シミュレータが 許可 を返すことを確認します。

External confirmation: run a FixVibe scan against your production URL. FixVibe checks your Firestore, Realtime Database, and Storage rules from the outside and reports what an attacker would find — independent of what the Firebase Console shows.

よくある質問

次のステップ

Run a FixVibe scan against your production URL — it confirms whether if true is currently exploitable from the public internet. For how the scanner covers Realtime Database and Storage as well, see Firebase rules scanner. For the equivalent class of misconfiguration on Supabase, read Supabase RLS scanner.