900 个站点，1.25 亿账户，1 个漏洞
Firebase 的安全模型及其陷阱
- 许多人认为 Firebase 的安全规则在概念上是合理的，但在实践中很难正确使用，尤其是 Realtime Database。
- 规则属于“设置后就忘记”：当业务逻辑变化时，新字段/集合往往会继承过于宽松的规则。
- 安全问题来自：
- 与传统后端相比，采用了新颖的基于规则的模型。
- 当许多应用使用同一平台时，很容易进行大规模扫描。
- 不安全的默认值 / “默认允许”模式，以及开发者只是为了让功能正常而直接使用
read/write true。
- 关于用户体验的批评：Firebase 大部分内容都有精致的 UI，但规则只是一个纯文本配置文件，很多较新的开发者都避而不正确地修改它。
Google 支持与组织问题
- 多条评论描述 Firebase/Google 的支持响应迟缓，而且大量外包。
- 有一种观点认为，Google 对面向开发者的产品，在以人为本、需要高技能的支持方面投入不足。
- 有些人认为这种“先机器人、后人工”的文化可能会让 Google 长期受损；另一些人则认为，监管或简单的组织惯性作用更大。
架构：前端直接访问数据库
- 许多人对前端直接写数据库感到不安，即使有规则也一样：
- 更难确保验证、内容检查以及不断变化的隐私要求。
- 与更集中式的后端相比，需要担心、容易遗忘的“表面面积”更大。
- 支持者表示，这种方式适用于简单的“仅用户数据”应用（例如笔记/同步），而成熟项目通常会把写操作迁移到 Cloud Functions 或传统服务器，同时将读取保留在客户端。
缓解措施与最佳实践
- 建议包括：
- 基于模板的“简单安全模式”和强制性的规则测试。
- 将每个集合视为具有明确的安全配置文件（公开、按用户、仅管理员），且绝不混合不同敏感级别。
- 默认拒绝的转译器，强制为新字段显式定义规则。
- 更好的审计日志，以及对隐式模式变化的通知。
- 类似 RLS 的机制（如 Postgres/Supabase 中的做法），用熟悉的语言来表达认证授权。
影响、伦理与用户安全
- 尽管多次尝试披露，许多存在漏洞的网站仍未修复；邮件经常被忽略，控制面板也很少有人查看。
- 关于是否公开受影响站点名单存在争论：这可能帮助用户，但也可能帮助攻击者。
- 更广泛的担忧是，低门槛的云工具让缺乏安全能力的组织也能收集大量 PII。
- 建议用户使用密码管理器，以及唯一或别名邮箱，以减少不可避免的数据泄露带来的损害。