为何Google官方文档不推荐Firebase用于多租户应用却有相关支持指引？

指引矛盾的核心原因 #

两个官方指引的适用前提完全不同，不存在实质冲突：

• Firebase基础最佳实践里的警告，针对的是直接使用原生Firebase默认能力开发多租户应用的场景。原生Firebase的底层设计最初就是面向单租户应用打造，所有项目级能力默认共享，没有内置的租户隔离逻辑，贸然用来做多租户确实很容易出现文档里提到的各类风险。
• 支持多租户场景的官方文档，针对的是搭配Google Identity Platform多租户能力、按照规范做了租户隔离适配的场景，本质是在Firebase基础能力之上叠加了专门的多租户支持，不属于警告里覆盖的错误用法。

原生Firebase裸写多租户的具体风险 #

就是官方警告里提到的几类问题，原生环境下几乎没有低成本的解决方案：

• 分析、崩溃监控等数据类能力都是项目全局聚合，没法自动按租户拆分，很容易出现跨租户的数据统计泄露、结果错误的问题
• 原生身份认证体系没有租户隔离逻辑，同一身份标识（比如邮箱、手机号）在整个项目里只能存在一个，没法满足不同租户下同一标识归属于不同用户的需求，也很容易出现跨租户的身份越权
• 数据库、存储等资源没有内置租户隔离，需要开发者手动在所有数据结构里加租户ID字段，且所有安全规则、业务逻辑都要手动补充租户ID校验，只要有一处漏写就会出现全量数据泄露的风险
• 远程配置、云函数、消息推送等能力都是项目级配置，没法按租户做独立的策略设置，业务复杂度会随租户数量上升呈指数级增长

Google Identity Platform多租户能力的作用 #

可以解决警告里提到的大部分核心安全缺陷，但不能覆盖所有问题：

已解决的核心问题 #

• 身份层完全隔离：可以在同一个项目下创建多个独立的租户实例，每个租户的用户池、认证配置完全独立，同一身份标识可以在不同租户下注册使用，认证请求会自动携带租户ID，从源头上避免了跨租户的身份越权问题
• 安全规则校验成本大幅降低：数据库、存储的安全规则可以直接读取认证请求自带的租户ID，不需要依赖客户端传入的参数做校验，大幅降低了规则漏写、被绕过的风险

仍需要自行适配的问题 #

• 分析、崩溃监控等数据能力仍然是项目全局聚合，需要开发者手动给事件打上租户标签，自己做数据拆分和权限控制
• 远程配置、消息推送、云函数等项目级能力仍然没有内置租户隔离，需要开发者自行根据租户ID做逻辑分支处理
• 数据层的结构仍然需要按照租户维度做设计，只是校验逻辑的可靠性更高

注：只要按照Google Identity Platform多租户的开发规范完成全链路的适配，Firebase完全可以用于生产级的多租户应用场景，官方的警告只是为了避免开发者在不了解底层限制的情况下直接用原生能力裸开发产生安全风险。

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