Firebase Firestore安全规则未定义属性访问最佳实践咨询

直接访问未确认存在的对象属性是否符合最佳实践 #

不符合。Firestore安全规则采用严格的属性访问校验逻辑，只要代码直接访问对象上不存在的属性，会立刻抛出Property uid is undefined on object类的运行时错误，直接判定请求拒绝，不会执行后续判断逻辑。这种写法一方面会导致漏传字段的合法请求无差别被拒，另一方面报错定位不清晰，会提升后续规则维护、问题排查的成本，完全不推荐使用。

是否应该在未确认uid存在的情况下直接访问该字段 #

不应该。你提到的先判断字段非空再做值比对的写法是可行的，安全规则的逻辑与判断遵循短路求值逻辑，只要把非空判断放在表达式最前面，就能避免访问不存在属性的报错：

allow write: request.resource.data.uid != null && request.auth.uid == request.resource.data.uid;

更严谨的存在性判断可以用in关键字实现，能区分「字段不存在」和「字段值显式传null」两种场景：

allow write: "uid" in request.resource.data && request.auth.uid == request.resource.data.uid;

自定义数据类型校验的可行方案 #

Firestore安全规则原生提供了完整的类型校验能力，可以从字段存在性、类型匹配、值合法性三个层面做完整校验，推荐把通用校验逻辑抽成自定义函数，减少重复代码，提升可维护性：

• 存在性校验：用"字段名" in 对象判断字段是否存在，比如"uid" in request.resource.data
• 类型校验：用is关键字匹配字段类型，支持string、int、bool、list、map等所有Firestore支持的数据类型，比如request.resource.data.uid is string可以确保uid字段为字符串类型，避免客户端传入数字、布尔值等非法类型绕过校验
• 值校验：可以针对字段值做范围、格式校验，比如字符串长度判断、数值大小判断等

优化后的健壮规则示例 #

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // 抽离categories集合写入的校验逻辑
    function validCategoryData() {
      return request.auth != null
        // uid字段校验：存在、字符串类型、和当前登录用户ID一致
        && "uid" in request.resource.data
        && request.resource.data.uid is string
        && request.resource.data.uid == request.auth.uid
        // name字段校验：存在、字符串类型、长度大于0
        && "name" in request.resource.data
        && request.resource.data.name is string
        && request.resource.data.name.size() > 0;
    }

    match /categories/{category} {
      // 读规则也需要先判断uid字段存在，避免存量无uid的文档触发属性不存在报错
      allow read: if request.auth != null
        && "uid" in resource.data
        && request.auth.uid == resource.data.uid;
      allow write: if validCategoryData();
    }
    match /expenses/{expense} {
      // 注意：当前无任何校验的全开放读写配置存在极高安全风险，生产环境必须补充权限校验逻辑，避免数据泄露、篡改
      allow read, write: if true;
    }
  }
}

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