Firestore安全规则与匿名登录：数据库遭篡改原因及防护有效性咨询

一、黑客篡改数据库的具体路径 #

你的原安全规则allow read, write;相当于完全开放数据库权限，黑客的攻击流程其实很直接：

• 获取项目公开配置：打开你的Web应用，通过浏览器开发者工具（F12）的「网络」面板，过滤Firestore相关请求，就能从请求/响应中提取出Firebase的项目配置信息（包括apiKey、projectId、authDomain等）。注意：这些配置本就是Web应用必须公开的前端参数，算不上“凭据泄露”，但你的规则没有权限限制，才让这些参数成为了攻击入口。
• 初始化Firestore客户端：用拿到的配置，自己编写一段简单的前端代码（或者用Firebase CLI），初始化Firestore SDK。
• 直接执行数据库操作：因为规则完全开放，不需要任何认证，直接调用Firestore的set()、update()、delete()等API，就能随意修改数据库里的内容。

二、匿名认证+规则调整的防护效果 #

你添加匿名认证并将规则改为allow read, write: if request.auth != null;，确实能显著提升安全性、降低攻击难度：

• 现在攻击者无法再仅凭公开的项目配置直接操作数据库，必须先完成Firebase的匿名认证流程，获取合法的认证令牌（auth token）后，才能发起读写请求。
• Firebase对匿名认证有默认的限流机制，能有效阻止批量自动化攻击，避免攻击者短时间内发起大量恶意请求。

不过需要注意：匿名认证只是基础防护，它允许任何能完成认证流程的用户操作数据库，如果你需要更严格的权限控制，还需要进一步细化规则——比如限制每个匿名用户只能访问/修改自己创建的数据，或者结合自定义Claims添加角色权限等。

内容的提问来源于stack exchange，提问作者Marc Van Daele