Firebase请求认证机制及恶意仿冒请求防范咨询

一、Firebase的风险现状 #

Firebase客户端SDK的配置信息（比如apiKey）本身就不属于保密范畴——这些内容会打包进你的移动应用安装包，只要有人反编译APK/IPA就能轻松获取。所以确实存在恶意用户利用这些信息仿冒你的应用向Firebase发起请求的可能，比如未经授权创建新用户、读写数据库数据，这就可能导致你自有后端数据库和Firebase数据不同步，完全符合你提到的风险场景。

二、针对性防范措施 #

1. 严格配置Firebase安全规则（核心手段） #

这和你自己后端限制用户仅操作自身数据的思路完全一致：

• Firebase Auth规则：如果不需要开放自由注册，可以限制用户只能通过指定第三方登录（如Google、Apple）；或者结合自定义令牌，仅允许后端签发的令牌完成用户创建。
• 数据库/存储规则：强制绑定用户身份，比如Firestore规则中设置request.auth.uid == resource.data.userId，确保用户只能修改自己的帖子、资料，只能访问自己上传的文件。
• 彻底关闭不需要的权限，比如禁止匿名用户访问任何资源。

2. 用自定义令牌管控用户创建流程 #

把用户注册的控制权收回到你的后端：

• 用户在应用内发起注册请求时，先提交到你的自有后端。
• 后端通过验证码、设备指纹等方式验证请求合法性，确认是真实用户后，用Firebase Admin SDK签发自定义令牌。
• 应用拿到令牌后，再向Firebase完成登录/注册操作。
  这种方式下，所有用户创建都必须经过你的后端审核，从根源上避免恶意注册。

3. 高风险操作转移到后端执行 #

对于批量数据修改、用户权限变更这类敏感操作，不要让客户端直接调用Firebase接口：

• 客户端先请求你的后端，后端验证用户身份和操作权限后，用Firebase Admin SDK执行对应操作。
• Admin SDK使用的服务账号密钥严格保密在你的后端服务器中，不会泄露给客户端，能确保操作的安全性。

4. 启用Firebase App Check #

App Check可以验证请求是否来自你的合法应用：

• 它会给你的应用颁发专属安全令牌，每次向Firebase发送请求时都会自动带上。
• Firebase会校验令牌有效性，直接拒绝未授权应用发起的请求，能有效拦截大部分伪造配置的恶意请求。

三、和你现有机制的匹配性 #

你自己后端基于用户身份限制操作范围的思路，和Firebase安全规则的核心逻辑完全契合——依赖用户身份做权限控制，而非客户端密钥，因为客户端的任何密钥都无法做到绝对保密，这才是移动应用后端安全的核心原则。

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