Firebase 规则扫描器:发现开放的 Firestore、Realtime Database 和 Storage 规则

扫描器如何找到开放的 Firebase 规则

Firebase 服务暴露众所周知、可预测的 URL 形状。没有凭据的扫描器可以探测每个服务并观察匿名读取是否成功。FixVibe 的 baas.firebase-rules 检查在每个 Firebase 服务上运行三个独立的探测:

• <strong>Firestore.</strong> The scanner extracts the project ID from the deployed app's bundle (it's in <code>firebase.initializeApp({ projectId: ... })</code>), then issues <code>GET https://firestore.googleapis.com/v1/projects/[project-id]/databases/(default)/documents/[collection]:listDocuments</code> against common collection names. A <code>200 OK</code> with documents in the response means <code>allow read</code> is permissive.
• Realtime Database。扫描器探测 https://[project-id]-default-rtdb.firebaseio.com/.json。如果根目录可匿名读取,响应就是整个数据库树的 JSON。更保守的测试查询 .json?shallow=true,它仅返回顶层键 — 无论哪种情况都是一项发现。
• Cloud Storage。扫描器查询 https://firebasestorage.googleapis.com/v0/b/[project-id].appspot.com/o。如果响应在无身份验证下列出文件名,则桶可匿名列出。即使单个文件下载被拒绝,可列出的存储也是一项发现 — 攻击者枚举桶以找到可猜测的文件名。

测试模式坑的真实面貌

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;
}

Realtime Database

<code>{ "rules": { "users": { "$uid": { ".read": "$uid === auth.uid", ".write": "$uid === auth.uid" } } } }</code>. The <code>$uid</code> wildcard captures the path segment for comparison.

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

Cloud Storage

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;
    }
  }
}

通过 Firebase CLI 部署规则:firebase deploy --only firestore:rules、firebase deploy --only database、firebase deploy --only storage。通过重新运行 FixVibe 扫描验证新规则已在生产中 — baas.firebase-rules 发现应被清除。

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

与 Firebase 内置工具的比较

Firebase 控制台向你显示当前规则,但不会根据运行时行为对其进行审计。Firebase Rules 模拟器让你用合成请求测试规则逻辑 — 有用但本地。这两个工具都不告诉你生产规则实际向公共互联网上的匿名攻击者返回什么。像 FixVibe (或手动配置的 Burp Suite) 这样的外部扫描器是唯一从攻击者相同视角探测的工具。Google 自己的 App Check 缓解滥用,但不能替代正确限定范围的规则。

常见问题

后续步骤

对你的生产 URL 运行免费的 FixVibe 扫描 — baas.firebase-rules 检查在每个套餐上都提供,并标记 Firestore、Realtime Database 和 Cloud Storage 中的开放规则。有关 allow read, write: if true 模式的更深入解释,请参阅 Firebase allow read, write: if true 解释。对于跨 Supabase、Firebase、Clerk 和 Auth0 的总览,请阅读 BaaS 配置错误扫描器。