Firestore文档所有权存储最佳实践 如何规避权限字段安全风险

核心疑问澄清 #

你提到的「用户可修改ownedBy字段篡改权限」的隐患，只要规则配置得当是完全可以规避的，且ownedBy字段的存储逻辑和直接存储canEdit这类权限配置有本质区别：

1. 你给出的示例规则中，update校验用的是resource.data.ownedBy，指的是修改前已存储在数据库中的文档数据，而非用户提交的待修改数据。也就是说用户要修改某份文档，首先必须已经是该文档的所有者，才有提交修改请求的资格。
2. 直接在业务文档存储{canEdit: true}这类配置出问题，通常是因为规则没有限制用户修改权限字段，导致用户可以自行把canEdit改为true越权。而ownedBy的校验锚定的是Firebase Auth签发的不可伪造的request.auth.uid，只要规则限制该字段不可修改，就不存在篡改空间。

推荐最佳实践 #

为了彻底堵上权限字段被篡改的可能，推荐按以下方式优化安全规则和存储逻辑：

• 创建阶段强制ownedBy字段为当前用户ID：示例规则中的create校验已经覆盖了这一点，即使用户提交请求时主动把ownedBy填为其他用户ID，也会直接被规则拦截，保证所有新创建的待办文档的所有者一定是创建人自己。
• 更新阶段显式禁止修改ownedBy字段：在原有update规则的基础上，增加校验逻辑要求用户提交的待修改数据中的ownedBy和数据库中已存储的ownedBy完全一致，确保该字段创建后不可变更。优化后的完整规则如下：

match /todos/{todo} {
    allow create: if request.auth.uid != null && request.resource.data.ownedBy == request.auth.uid;
    allow read, delete: if resource.data.ownedBy == request.auth.uid;
    allow update: if resource.data.ownedBy == request.auth.uid 
                   && request.resource.data.ownedBy == resource.data.ownedBy;
}

• 细粒度权限单独存储：如果业务需要支持多用户协作（比如待办共享给其他用户编辑），不要把editableUidList这类权限配置直接存在待办文档中，应该把权限配置存在独立的、仅云函数/管理员可修改的集合中，避免用户自行修改权限列表越权。
• 所有鉴权逻辑锚定不可伪造属性：所有安全规则的校验核心必须锚定request.auth.uid这类由官方签发、用户无法篡改的属性，不要完全依赖用户可编辑的业务字段做权限判断。

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