审计 Firebase 安全规则漏洞时使用的红队检查清单与评…

当你需要以红队视角审查 Firestore/Cloud Storage 安全规则、找出权限提升与校验绕过并给出 1-5 分评分时使用。

适用场景

解决思路

1. 以红队渗透测试视角审查规则：不要因为规则看起来复杂就假定它安全，主动构造一串操作序列尝试绕过它。
2. 检查 Update Bypass：对比 create 与 update 规则，判断用户能否先创建一个合法文档、再通过 update 把它改成非法或恶意状态（例如修改自己的 role、绕过大小限制、破坏数据类型）。
3. 检查 Authority Source：确认敏感字段（如 role、isAdmin、ownerId）的权限是否依赖用户可控数据 request.resource.data，并仔细追溯该权限来源。
4. 检查 Business Logic vs. Rules：判断规则集是否真正支持应用目的（例如协作类应用中协作者是否真的能读到数据），若不能则标记为规则“损坏”或会迫使采用不安全变通方案。
5. 检查 Storage Abuse：确认是否有字符串长度或数组大小限制，若没有则标记为 Resource Exhaustion/DoS 风险。
6. 检查 Type Safety：确认字段是否用 is string、is int、is timestamp 等做了类型校验。
7. 检查 Field-Level vs. Identity-Level Security：警惕使用 hasOnly() 或 diff() 的规则，它们只限制能更新哪些字段，不限制谁能更新；除非同时存在所有权检查（如 resource.data.uid == request.auth.uid），否则任何已认证用户都能更新他人文档字段，属于数据完整性漏洞。
8. 处理 Admin Bootstrapping 与特权：若规则使用单个硬编码管理员邮箱（如 request.auth.token.email == 'admin@example.com'），只要同时检查了 email_verified（request.auth.token.email_verified == true）且实现方式不允许其他管理员自我添加或留下提权风险，就不应扣分。
9. 按 1-5 分评分：1（Critical）未授权数据访问/泄露、权限提升或完全绕过校验；2（Major）业务逻辑损坏、自我分配角色、绕过控制；3（Moderate）PII 暴露（如公开邮箱）、关键字段 create 与 update 校验不一致；4（Minor）仅影响用户自身数据的更新绕过、缺少大小限制、缺少次要类型检查、非敏感字段读权限过宽；5（Secure）全面校验、严格所有权、通过安全 ACL 实现基于角色的访问。
10. 以 JSON 格式返回评估结果，结构为 {"score": 1, "summary": "overall assessment", "findings": [{"check": "checklist item", "severity": "critical|major|moderate|minor", "issue": "description", "recommendation": "fix"}]}。

适用边界 · 注意事项

• 不要用于 Firebase CLI 相关任务（login、deploy）。
• 不要用于 Auth、Crashlytics、Remote Config 或数据库查询。
• 不要用于非 Firebase 安全规则审查的场景。