Firestore按文档owner属性配规则报权限不足及数据结构选型咨询

安全阿岳

2026-9-3

权限报错原因与修复方案

规则逻辑存在缺陷，未区分读写场景的判断对象
你当前规则统一用resource.data.owner做权限判断，但resource仅指向数据库中已存在的文档：
- 新建文档时，目标文档尚未入库，resource.data为null，规则会直接拒绝所有新建请求，根本无法写入带owner字段的合法文档
- 你早期未配置规则时创建的历史文档本身没有owner字段，resource.data.owner取值为null，永远无法匹配登录用户的uid，会被直接拦截
规则匹配范围过大，未按集合路径做精准匹配
你用递归通配符/{document=**}匹配了数据库下所有路径的文档，包含非业务集合、系统隐含文档，规则校验时无法确认你的查询仅会访问tasks集合下符合权限的文档，会直接判定查询不满足安全要求。
历史数据缺失必要字段
无owner字段的历史文档本身不满足权限判断逻辑，哪怕查询加了owner过滤条件，规则也会因为存在不符合权限要求的存量数据，拦截整个查询请求。

可直接使用的正确规则示例：

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // 精准匹配tasks集合下的单文档
    match /tasks/{taskId} {
      // 读权限：用户已登录，且文档owner字段对应当前用户uid
      allow read: if request.auth != null && request.auth.uid == resource.data.owner;
      // 新建权限：用户已登录，写入的新文档owner字段必须为当前用户uid
      allow create: if request.auth != null && request.resource.data.owner == request.auth.uid;
      // 更新/删除权限：仅所有者可操作，且禁止修改owner字段转移所有权
      allow update, delete: if request.auth != null 
        && request.auth.uid == resource.data.owner 
        && request.resource.data.owner == resource.data.owner;
    }
    // workspaces等其他业务集合按相同逻辑配置即可
    match /workspaces/{workspaceId} {
      allow read: if request.auth != null && request.auth.uid == resource.data.owner;
      allow create: if request.auth != null && request.resource.data.owner == request.auth.uid;
      allow update, delete: if request.auth != null 
        && request.auth.uid == resource.data.owner 
        && request.resource.data.owner == resource.data.owner;
    }
  }
}

修复操作步骤：

替换上述安全规则
执行一次性脚本，给所有早期创建的缺失owner字段的文档补全对应归属字段
确保所有查询tasks等业务集合的请求，都携带where('owner', '==', 当前登录用户uid)的过滤条件——Firestore安全规则不会自动过滤无权限文档，必须由查询本身保证返回结果全部符合权限要求。

多用户场景下的数据结构选型

业界通用最佳实践是方案1（通过文档属性标识归属），不推荐方案2的用户独立集合结构，核心原因如下：

扩展性差异：方案1只需要新增字段（比如members共享成员数组、visibility公开标识）就能快速支持任务共享、团队协作、公开内容等后续需求；方案2如果要实现跨用户访问，需要做多份数据冗余，一致性维护成本极高。
查询能力差异：方案1可以灵活支持跨维度统计、全局筛选（比如统计全平台高优先级任务数量、筛选所有带特定标签的公开任务）；方案2需要遍历所有用户的子集合才能实现同类查询，性能差甚至无法落地。
运维成本差异：方案1的集合数量固定，索引配置、数据备份、运维排查成本极低；方案2的根集合数量和用户量正相关，用户规模上来后运维成本会指数级上升。
权限适配差异：方案1的字段级权限判断和Firestore安全规则、索引机制的适配性更好，只要查询携带对应过滤条件就能稳定通过校验，性能和单用户集合无差异。

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