Firestore存储及实时数据库安全规则配置问题咨询

方案1：限制请求来源为已注册应用 #

可以通过验证请求的应用包名/签名哈希来限制仅允许你注册的应用发起请求，但需注意：这种方式无法完全阻止技术手段伪造签名的恶意访问，仅能作为基础防护层。

Firestore Storage 规则示例 #

rules_version = '2';
service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read, write: if 
        // 验证Android应用包名和签名哈希
        (request.auth.token.android.app_package_name == "你的安卓包名" && 
         request.auth.token.android.app_signature_hash == "你的安卓签名哈希")
        // 追加iOS应用验证
        || (request.auth.token.ios.bundle_id == "你的iOS bundle ID");
    }
  }
}

注：需在Firebase控制台「项目设置」→「应用」中获取对应平台的签名哈希（Android）或Bundle ID（iOS），确保应用已正确集成Firebase SDK。

Realtime Database 规则示例 #

{
  "rules": {
    ".read": "request.auth.token.android.app_package_name == '你的安卓包名' || request.auth.token.ios.bundle_id == '你的iOS bundle ID'",
    ".write": "request.auth.token.android.app_package_name == '你的安卓包名' || request.auth.token.ios.bundle_id == '你的iOS bundle ID'"
    // 可按需细化到特定节点，比如仅允许访问用户专属消息目录
  }
}

方案2：限制仅认证用户访问（修复你遇到的问题） #

你之前使用的allow read, write, delete: if request.auth != null;规则本身有效，未生效通常是以下原因：

1. 规则未正确发布到生产环境；
2. 部分数据节点设置了更宽松的自定义规则，覆盖了全局规则；
3. 已泄露的文件URL关联了旧的公开权限（需重新设置文件权限）。

正确的权限规则配置 #

Firestore Storage 规则

rules_version = '2';
service firebase.storage {
  match /b/{bucket}/o {
    // 全局规则：仅认证用户可访问
    match /{allPaths=**} {
      allow read, write, delete: if request.auth != null;
    }
    // 可选：细化权限，用户仅能访问自己的附件目录
    match /user-attachments/{userId}/{allPaths=**} {
      allow read, write, delete: if request.auth.uid == userId;
    }
  }
}

Realtime Database 规则

{
  "rules": {
    // 全局规则：仅认证用户可读写
    ".read": "request.auth != null",
    ".write": "request.auth != null",
    // 可选：细化到消息节点，用户仅能访问自己的消息
    "messages": {
      "$userId": {
        ".read": "request.auth.uid == $userId",
        ".write": "request.auth.uid == $userId"
      }
    }
  }
}

生效验证步骤 #

1. 在Firebase控制台的「Storage」/「Realtime Database」规则编辑器中发布上述规则；
2. 清除应用缓存并重启，测试未登录状态下是否能访问数据；
3. 若之前有公开权限的文件，需手动批量更新权限或重新上传替换旧URL。

内容的提问来源于stack exchange，提问作者a.castro