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 的快速入门文档包含互联网上被最多复制的规则块之一:

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 规则是运行时紧急事件。修复在三个服务上形状相同:将每条规则限定到 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 Rules 模拟器让你用合成请求测试规则逻辑 — 有用但本地。这两个工具都不告诉你生产规则实际向公共互联网上的匿名攻击者返回什么。像 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.