App用户能否在客户端查验获取到的Firestore原始数据？

前端UI层面的字段隐藏没有任何安全防护作用，只要完整的用户文档被传输到客户端，用户就一定有办法读到所有字段，和你在页面上展不展示没有关系：

• 在React Native等移动端场景，用户可以通过抓包工具（配置自签证书即可解密HTTPS流量）直接查看接口返回的完整响应内容，越狱/root设备还可以直接读取应用的本地缓存、内存数据，拿到所有拉取到的字段。
• 在Web场景下这个风险的利用门槛极低：用户不需要装任何抓包工具，只要按F12打开浏览器开发者工具，在网络面板里就能直接看到接口返回的全量数据，甚至在控制台写几行简单的脚本就能遍历页面加载到的所有用户隐私信息，完全没有技术门槛。

你需要记住一个最基础的客户端安全原则：所有前端做的权限控制、内容隐藏，都只是优化体验的UI层逻辑，绝对不能作为数据安全的边界。安全边界必须落在服务端，任何不应该被用户看到的数据，从一开始就不应该传输到客户端。

你目前想到的拆分UsersPublicInfo和UsersPrivateInfo两个集合的思路是对的，完全不需要担心那两个问题：

• 关于读操作翻倍：实际业务场景下，绝大多数请求都是用户列表、内容页作者信息展示这类只需要公开字段的场景，这类请求只需要拉取公开集合的文档即可；只有当用户进入个人详情页、且当前访问者确实具备查看隐私信息的权限时，才需要单独拉取对应私有文档，整体读操作量不仅不会翻倍，反而会比全量拉取完整文档低很多，同时还能减少流量消耗。
• 关于私有字段无法查询的问题：如果确实需要用dob这类私有字段做查询条件（比如按年龄筛选用户），完全不需要把私有字段暴露给客户端。你可以把这类涉及私有字段的查询逻辑放到服务端/云函数中执行：服务端拿到查询参数后，关联私有数据完成筛选，最终只把符合条件的用户的公开字段返回给客户端，全程不会把私有字段传输到请求方侧。

这里额外提一句文档型数据库的权限特性：包括Firestore在内的绝大多数文档数据库，安全规则只能控制「用户能不能读整个文档」，做不到「同一个文档对不同权限的用户返回不同字段」。如果你把公开和私有字段存在同一个文档里，只要给了用户读这个文档的权限，他就能拿到文档里的所有内容，这本身就是权限设计上的缺陷。

除了分集合存储之外，你也可以根据自己的业务复杂度选其他方案：

• 服务端代理请求：客户端不直接直连数据库，所有用户数据请求都走你自己的服务端接口，服务端校验完请求者权限后，把需要返回的字段做一层过滤，剔除隐私字段后再响应给客户端。这个方案不需要改动现有数据库结构，但是会增加服务端的开发维护成本，也会损失BaaS直连带来的部分性能优势。
• 端到端加密存储：对于敏感度极高的隐私字段，在客户端写入时就用用户本地持有的密钥加密后再存到数据库，就算数据被非法拉取，没有对应密钥也无法解密得到明文。但这个方案实现复杂度很高，普通的用户资料场景没必要使用。

最后再强调一次：只要数据传到了用户可控的设备上，就等于你把数据直接交到了用户手里，靠前端藏字段的做法和掩耳盗铃没有区别。

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