Firebase ルールスキャナ: 開いている Firestore、Realtime Database、Storage ルールを検出

スキャナが開いた Firebase ルールを見つける仕組み

Firebase services are reachable at predictable public addresses, so a scanner with no credentials can check each one the way an anonymous visitor would. FixVibe's Firebase check covers all three services independently:

• Firestore. FixVibe finds the project from the deployed app's own Firebase configuration and reports collections that anonymous visitors can read.
• Realtime Database. FixVibe reports a database whose data anonymous visitors can read — often the whole tree at once.
• Cloud Storage. FixVibe reports buckets that anonymous visitors can list. Listable storage is a finding even when individual downloads are denied, because it lets attackers find guessable filenames.

テストモードの落とし穴の実際の姿

Firebase のクイックスタートドキュメントには、インターネット上で最もコピーされているルールブロックの 1 つが含まれています:

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

Firebase はかつてこれらのルールに 30 日間の自動期限を追加していました。それは変わりました: 今日では、開発者がそれらを置き換えない限り、ルールは永遠に持続します。AI コーディングツールは — テストモードブロックを含む数年分のドキュメントで訓練されているため — それを逐語的に発し、開発者に「これがあなたのセキュリティルールです」と伝えることがよくあります。そうではありません。

本番に現れるが同様に許容的な他のバリアント:

// future-date variant — equivalent to "if true"
allow read, write: if request.time < timestamp.date(2099, 1, 1);

// authenticated-user variant — any signed-in user reads and writes anything
allow read: if true;
allow write: if request.auth != null;

// any-auth variant — any signed-in user owns every document
allow read, write: if request.auth != null;

• 未来のタイムスタンプバリアント: 遠い未来の日付まですべてを許可するルール。事実上期限切れにならない (上のハイライトされたブロックを参照)。
• allow read: if true; allow write: if request.auth != null; — 公開読み取り、認証済みユーザーは誰でも書き込み可能。
• allow read, write: if request.auth != null; — サインインしたユーザーは誰でも、他のユーザーのデータを含む任意のドキュメントを読み書き可能。

スキャナが開いたルールを見つけたときの対応

開いた Firebase ルールはランタイムの緊急事態です。修正の形は 3 つのサービスすべてで同じです: すべてのルールを request.auth.uid でスコープし、明示的な所有者フィールドと照合します。各サービスにはそれぞれのルール構文があります:

Firestore

match /users/{userId} { allow read, write: if request.auth != null && request.auth.uid == userId; }。パスセグメントバインディング {userId} がユーザーが触れることのできる唯一のドキュメントになります。

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

リアルタイムデータベース

{ "rules": { "users": { "$uid": { ".read": "$uid === auth.uid", ".write": "$uid === auth.uid" } } } }。$uid ワイルドカードは比較用にパスセグメントをキャプチャします。

{
  "rules": {
    "users": {
      "$uid": {
        ".read":  "$uid === auth.uid",
        ".write": "$uid === auth.uid"
      }
    }
  }
}

クラウドストレージ

service firebase.storage { match /b/{bucket}/o { match /users/{userId}/{allPaths=**} { allow read, write: if request.auth.uid == userId; } } }。慣例: ファイルを users/[uid]/[filename] 配下に保存し、パスで所有権を強制します。

service firebase.storage {
  match /b/{bucket}/o {
    match /users/{userId}/{allPaths=**} {
      allow read, write: if request.auth.uid == userId;
    }
  }
}

Deploy rules via the Firebase CLI: firebase deploy --only firestore:rules, firebase deploy --only database, firebase deploy --only storage. Verify the new rules are in production by re-running the FixVibe scan — the open-rules finding should clear.

firebase deploy --only firestore:rules
firebase deploy --only database
firebase deploy --only storage

Firebase 組み込みツールとの比較

Firebase コンソールは現在のルールを表示しますが、ランタイムの挙動と照らし合わせて監査することはありません。Firebase ルールシミュレータは合成リクエストに対してルールロジックをテストさせてくれます — 有用ですがローカルです。どちらのツールも、公開インターネット上の匿名攻撃者にあなたの本番ルールが実際に何を返すかは教えてくれません。 FixVibe のような外部スキャナ (または手動構成された Burp Suite) だけが、攻撃者と同じ角度から探ります。Google 自身の App Check は悪用を緩和しますが、正しくスコープされたルールの代わりにはなりません。

よくある質問

次のステップ

Run a free FixVibe scan against your production URL — the Firebase rules check runs on every plan and flags open rules across Firestore, Realtime Database, and Cloud Storage. For a deeper explainer on the allow read, write: if true pattern specifically, see Firebase allow read, write: if true explained. For the umbrella view across Supabase, Firebase, Clerk, and Auth0, read BaaS misconfiguration scanner.