无认证场景下Firestore规则与App Check的合规性及优化咨询

1. 是否可忽略谷歌的安全警告？ #

绝对不能忽略。虽然你启用了App Check，但当前全开放的Firestore规则意味着任何通过App Check校验的请求都能读写整个数据库的所有内容——包括批量删除所有用户数据、篡改他人配置或提交的文本。App Check确实能拦截大部分无授权的爬虫或恶意工具，但如果有人逆向你的App获取到App Check的密钥，就能发起大量恶意请求，数据泄露或被破坏的风险极高。谷歌的警告是基于规则本身的安全漏洞发出的，必须针对性修复。

2. 无需用户认证的场景下是否必须实现注册认证？ #

不需要强制用户注册账号，但必须使用Firebase的匿名认证。匿名认证完全不需要用户输入任何信息，会自动为每个首次打开App的用户生成唯一的用户ID，既能保持无感知的使用体验，又能基于这个ID为用户划分数据权限，从根本上解决全开放规则的安全问题。

3. 是否需要调整应用架构？ #

不需要大幅调整现有架构，只需要优化数据组织方式和权限控制逻辑：

• 调整Firestore的数据结构：将每个用户的配置、提交的文本存放在以其匿名用户ID为路径的节点下，比如/users/{userId}/notificationSettings、/users/{userId}/submittedTexts，避免所有用户的数据混存
• 结合匿名认证配置Firestore规则，限制用户只能访问自己节点下的数据

这种调整只是在现有架构基础上补充权限分层，不会影响核心功能的实现。

4. 是否有其他优化方案？ #

• 细化Firestore安全规则：结合匿名认证和App Check双重校验，示例规则如下：

  service cloud.firestore {
    match /databases/{database}/documents {
      match /users/{userId}/{documents=**} {
        allow read, write: if request.auth != null && request.auth.uid == userId && request.app != null;
      }
    }
  }
  

• 启用Firestore审计日志：开启数据库的访问日志监控，及时发现异常的读写请求
• 数据校验与限制：在客户端和Firestore规则层同时对用户提交的文本做长度、格式校验，避免垃圾数据占用存储
• 定期清理无效数据：通过Firebase云函数定期删除超过一定时长的匿名用户数据（比如30天未活跃的用户），降低存储成本和数据泄露风险

内容的提问来源于stack exchange，提问作者Luke