Firebase 的 Realtime Database 与 Cloud Firestore 都通过安全规则控制读写权限。客户端发起请求时，Firebase 会先完整评估规则表达式，只有当某条 allow 语句被判定为 true 时，请求才会放行；否则返回 PERMISSION_DENIED。很多拒绝访问并不是数据库本身不可用，而是规则配置存在逻辑漏洞、版本声明缺失或条件判断与数据结构不匹配。定位这类问题需要从规则文本、请求路径和调用方身份三个维度同时核对。
先确认规则版本与基础结构
Cloud Firestore 与 Realtime Database 的规则语法不同，混用会直接导致规则无法生效。Cloud Firestore 规则文件的第一行必须声明 rules_version = '2';，否则部分表达式特性不会启用。规则主体由 service cloud.firestore 开始，并在 match /databases/{database}/documents 下逐级匹配文档路径。如果路径层级写错，例如把 {document} 写成 {doc}，规则不会作用于目标集合，Firebase 会按默认拒绝策略处理请求。
Realtime Database 规则则以 JSON 形式写在 rules 节点下，通过 .read 与 .write 字段控制权限。它没有 Firestore 的版本声明，但同样要求路径段与通配符名称保持一致。一个常见的错误是使用 .validate 时只约束新数据，却忽略了 .write 本身是否放行。权限判断顺序是先看读写是否允许，再执行数据校验，因此只写 .validate 而 .write 返回 false，依然会拒绝访问。
// Cloud Firestore 规则基础结构
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
match /users/{userId} {
allow read, write: if request.auth != null && request.auth.uid == userId;
}
}
}
常见规则配置错误与修复方式
返回 PERMISSION_DENIED 时，最先要检查的是 request.auth 是否为 null。匿名登录未启用、令牌过期、客户端未等待认证完成就发起查询，都会让规则中的 request.auth != null 判断为 false。更隐蔽的问题是认证域不匹配：Firebase 控制台中若同时启用了多个认证方式，但应用实际使用 Google 登录，而规则里要求 request.auth.token.email_verified == true，某些第三方身份可能没有这一字段，也会被判定为不满足条件。
通配符绑定错误同样高发。规则中 match /users/{userId} 的 userId 只匹配单一路径段，如果客户端读取的是 /users/abc/profile，这条规则不会命中，因为还需要继续匹配 /profile 子路径。正确的做法是使用递归通配符 {document=**} 或在子集合中单独声明规则。另一个典型错误是把通配符名称用于条件判断时拼写不一致，例如 match /users/{userId} 中条件写成 request.auth.uid == userID，由于大小写不同，条件恒为 false。
条件逻辑写反也不少见。例如需求是“只有文章作者可以修改，其他登录用户可以阅读”，但规则写成 allow read: if isAuthor(); allow write: if isAuthor(); 会让普通用户无法读取。正确写法应将读写权限拆开：读权限对所有登录用户开放，写权限仅对作者开放。此类逻辑错误不会提示语法问题，只能通过模拟器或真实请求验证。
// 分离读写权限的示例
match /articles/{articleId} {
allow read: if request.auth != null;
allow write: if request.auth != null && request.auth.uid == resource.data.authorId;
}
使用控制台模拟器定位拒绝访问
Firebase 控制台内置的规则模拟器是排查拒绝访问最直接的工具。在 Firestore 的 Rules 页面中，可以指定读取类型、文档路径以及是否携带认证信息，然后观察规则评估结果。模拟器会逐条展示每条 allow 语句的命中情况，如果某条语句因为 request.auth 为 null 而未通过，结果中会明确标出。相比直接修改线上规则后用客户端反复测试，模拟器不会影响真实数据，也不会触发错误日志。
使用模拟器时，建议先构造一个与真实请求完全一致的路径。例如客户端查询的是 /users/uid123/orders/order001，就不要只测 /users/uid123。如果模拟结果显示权限通过，但客户端仍然被拒绝，则应检查客户端实际访问的集合名称、环境变量是否指向了错误的项目，或者是否使用了 Firestore 的数据库实例 ID 而规则未覆盖对应实例。
还可以在客户端启用 Firestore 日志，查看请求携带的认证信息和实际路径。Android、iOS 与 Web SDK 提供调试日志，能输出 Firestore (version) ... 之类的请求详情。将日志中的路径与规则匹配层级对比，通常能快速发现 match 是否写错层级，或者集合名称是否存在拼写偏差。
上线前的最小权限规则与检查清单
修复规则时，不要为了快速恢复访问而使用 allow read, write: if true; 这类全开放规则。即使在测试环境，也应保持最小权限原则。可以先从只允许认证用户读取开始，再按资源归属逐步收紧写权限。例如用户资料规则只允许本人写入，订单记录则只允许创建者读取，管理员通过自定义声明 request.auth.token.admin == true 获得更高权限。
上线前需要逐项核对：规则版本是否正确；每个集合是否都有对应的 match 路径；条件中使用的字段是否真实存在于文档或认证令牌中；递归通配符是否只出现在必要位置；是否所有 request.auth != null 的判断都考虑到了匿名登录。对于 Firestore，还应检查 resource.data 在创建文档时是否可用。创建操作中 resource 指向未来文档，但部分字段可能尚未写入，不能用 resource.data.field 做过于严格的校验，否则写入会被拒绝。
// 创建操作用 request.resource 校验即将写入的数据
match /posts/{postId} {
allow create: if request.auth != null
&& request.resource.data.title is string
&& request.resource.data.title.size() < 100;
}
最后建议在 Firebase 控制台中为关键集合添加测试用例，覆盖未登录访问、跨用户访问、非法字段写入和正常读写四类场景。每次修改规则后先运行模拟器再发布，能够显著降低因配置错误导致的拒绝访问问题。若生产环境已经出现大面积 PERMISSION_DENIED，应先回滚到上一版可用的规则，再在测试项目中复现并修复，避免在线调试扩大影响范围。
Firebase数据库规则拒绝访问安全规则修改时间：2026-08-23 09:01:07