如何保护Golang及iOS Swift应用中的Firebase凭证文件？

核心前提 #

任何嵌入客户端（桌面/移动端）的敏感凭证，理论上都能被逆向提取——只是提取难度有高低之分。所以保护的核心思路是：降低凭证泄露后的危害，而非完全阻止提取。

Golang桌面应用方案 #

1. 优先使用Firebase客户端SDK，避免嵌入服务账号JSON #

不要直接嵌入Firebase服务账号（Admin SDK用的JSON），这类账号权限极高，能对数据库执行任意操作，一旦泄露危害极大。
改用Firebase客户端SDK的配置（仅包含apiKey、projectId等受限字段），这类密钥的权限被Firebase控制台限制（比如只能用于客户端身份验证、读取公开数据），就算被提取，攻击者也无法执行恶意的批量操作。

2. 必须用Admin SDK时，通过自建后端中转 #

如果你的应用依赖Admin SDK的高级权限，绝对不能把服务账号嵌入客户端：

• 搭建自己的API/WebSocket服务器，将Firebase服务账号存储在服务器端；
• 服务器用Admin SDK监听Firebase实时数据的Snapshot变化，再通过WebSocket把数据推送给桌面客户端；
• 桌面客户端仅与你的服务器交互，用Firebase Auth的ID Token做用户鉴权，服务器验证通过后才处理请求。

3. 对敏感信息做混淆（仅提高逆向门槛） #

如果一定要在客户端嵌入受限的密钥，可以做简单混淆：

• 将密钥字符串拆分为多个片段，运行时动态拼接；
• 用XOR等轻量加密算法加密密钥，运行时在内存中解密。
  注意：这种方法只能过滤低级攻击者，专业逆向人员仍能破解，仅作为辅助手段。

iOS Swift应用（上架App Store）方案 #

1. 仅使用官方客户端配置文件 #

直接使用Firebase提供的GoogleService-Info.plist，该文件中的API_KEY是客户端专用密钥，你可以在Firebase控制台设置：

• 绑定应用的Bundle ID；
• 开启App Store签名校验；
  就算密钥被提取，攻击者也无法在其他应用中滥用。

2. 开启Firebase App Check（关键防护） #

App Check会验证所有来自iOS应用的请求是否合法：

• 启用后，Firebase会通过Apple的DeviceCheck框架验证设备和应用的合法性；
• 就算攻击者拿到密钥，也无法伪造合法请求访问Firebase服务。

3. 对plist中的敏感字段做混淆 #

可以对GoogleService-Info.plist中的敏感字段做处理：

• 将密钥拆分为多个子字符串，存储在代码的不同位置，运行时再组合；
• 用AES加密密钥后存储，运行时在内存中解密（注意不要把加密密钥硬编码在代码里，可以结合设备唯一标识生成，进一步提高门槛）。

4. 绝对禁止嵌入服务账号信息 #

Firebase服务账号只能部署在你的后端服务器，永远不要将其放入iOS应用的任何文件中。

关于实时Snapshot Listeners的适配 #

如果你的应用依赖Firebase的实时监听功能：

• 使用客户端SDK时，SDK本身支持直接监听数据变化，无需暴露高权限凭证；
• 若必须用Admin SDK的监听能力，通过自建后端中转：服务器用Admin SDK监听Firebase数据，再通过WebSocket将实时更新推送给客户端，客户端与服务器保持长连接即可实现类似效果。

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