对接移动应用的Firebase项目安全：HTTP地址隐藏问题咨询

你顾虑的“逆向获取项目HTTP地址带来风险”，首先需要明确Firebase的设计逻辑：SDK集成所需的项目标识、服务接口地址、公开API Key这类信息，从产品设计之初就定义为可公开的标识类信息，本身不具备权限校验效力。

• 常规集成流程中，这类配置会被打包进应用安装包的资源目录（安卓对应google-services.json、iOS对应GoogleService-Info.plist），只要是随安装包分发的内容，逆向手段必然可以完整提取，这是无法彻底规避的客观现实。
• 你提到的代码混淆无法解决该问题是客观事实：代码混淆仅能对代码内的类名、方法名做符号替换，不会对资源文件、二进制存储段内的明文字符串做不可逆加密——如果真把配置值加密到SDK无法解析的程度，只会直接导致Firebase初始化失败，完全得不偿失。

既然地址无法彻底藏住，完全可以通过以下方案覆盖你担心的风险，不需要在“加密存储地址”上浪费精力：

• 把安全边界从客户端转向服务端权限控制。哪怕攻击者完整拿到你的Firebase项目配置，只要你配置了严格的Firebase安全规则、绑定强身份校验逻辑（比如仅登录用户可访问对应数据、用户仅能操作自身权限范围内的资源），攻击者没有合法的会话凭证，根本无法越权读取、篡改项目数据，最多只能获取项目的公开基础信息。
• 开启Firebase App Check防护。这是官方专门针对“扒取公开配置恶意刷接口、消耗项目配额”场景设计的能力，会对每一个请求的来源做合法性校验，仅放行来自你官方上架应用的请求，阻止第三方脚本、非法逆向客户端直接调用你的Firebase服务，从根源上解决配置被滥用的问题。
• 若想降低低烈度爬虫的爬取效率，可以将Firebase初始配置调整为客户端启动后从自有鉴权接口动态拉取。但需要明确：这种方式没有本质的防逆向能力——客户端拿到配置后最终要在内存中解析、构造网络请求，抓包、内存转储手段依然可以获取到接口地址，它仅能防范直接静态扒取安装包字符串的初级攻击，不能作为核心安全依赖。

不存在能完全脱离客户端转发对应接口地址的对接模式。客户端要和Firebase服务建立通信，必然要在本地完成地址解析、请求构造的全流程，不管是硬编码在源码中、还是动态从自有服务器拉取，接口地址最终都会出现在客户端运行时内存和网络链路中，逆向手段100%可以获取。投入资源在“加密隐藏地址”上的成本，远低于搭建好服务端权限、App Check防护的实际收益。

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