Firebase Admin SDK推送通知安全实现及密钥防护最佳实践

核心底线：service-account.json 属于服务端最高敏感凭证，绝对不能出现在你可控服务端边界之外的任何位置，所有开放给客户的能力都要通过你自己的服务层做中转和管控，不要让客户直接接触Firebase侧的任何认证信息。

一、基础架构设计 #

• 单独部署推送中转服务，作为整个系统里唯一加载Firebase Admin SDK、唯一持有service-account.json的模块。这个服务只跑在你完全管控的服务端环境，不对外暴露任何和Firebase凭证相关的接口。
• 凭证存储不要硬编码、不要提交到Git仓库，统一放到加密密钥管理服务（KMS）或者加密配置中心，服务启动时才拉取解密后加载到内存，运行过程中禁止打印、输出凭证相关的任何字段。
• 所有客户的推送请求，全部走你自己平台的开放API对接这个中转服务，客户侧全程只和你的平台API交互，完全感知不到Firebase的存在。客户和你平台API之间的鉴权，用你平台自建的认证体系就行：比如给每个接入客户分配独立的AK/SK、或者走平台统一的OAuth2授权流程，和Firebase凭证完全解耦。

二、权限管控规则 #

• 强租户隔离：中转服务收到客户的推送请求后，第一校验推送目标（设备token、主题名）的归属权，确保当前鉴权通过的客户，只能给自己名下绑定的终端用户发推送，跨租户的请求直接拦截返回403，避免恶意客户遍历token滥发消息。
• 服务账号最小权限：不要用Firebase初始化时默认生成的全权限服务账号，去GCP IAM控制台单独建一个专用服务账号，只给它分配Firebase Cloud Messaging Admin这一个角色，其他所有GCP资源、Firebase其他模块的权限全部移除。就算极端情况凭证泄露，影响范围也被严格限制在推送能力内，不会拖库或者泄露其他业务数据。
• 加频控和内容校验：在中转层做单客户推送频率限制、敏感内容拦截，避免客户滥用通道发垃圾消息，导致你的Firebase应用被平台风控限流甚至封禁。
• 定期轮换凭证：每90天轮换一次服务账号密钥，整个轮换流程在你服务端侧无感完成，客户侧不需要做任何适配，不会影响业务。

三、绝对禁止的错误操作 #

以下操作会直接造成凭证泄露或者权限失控，必须完全规避：

• 将service-account.json打包到客户端APP、前端Web代码、客户私有化部署的程序包里
• 为了省开发量，直接把Firebase服务账号凭证发给客户，让客户自己对接Firebase原生接口
• 中转层不做租户归属校验，只要请求带了平台API Key就允许给任意设备token发推送
• 给推送专用的服务账号分配FCM推送之外的多余权限，比如云存储读写、数据库操作、用户管理权限

四、进阶加固方案 #

• 如果你的服务部署在GCP生态上，可以完全不用落地静态service-account.json文件：给运行推送中转服务的计算实例（GCE、GKE、Cloud Functions、Cloud Run）直接绑定最小权限的服务账号，Firebase Admin SDK启动时会自动获取临时轮换的访问凭证，从根源上消除静态密钥文件泄露的风险。
• 全链路留审计日志：记录每一条推送请求的调用方客户ID、推送目标、请求时间、推送内容、Firebase返回结果，出现滥发、错发问题时可以快速溯源定位。
• 高安全等级场景可以给API加额外校验：比如接口请求签名校验、客户出口IP白名单、单请求推送目标数量上限，进一步降低接口被爆破滥用的风险。

内容的提问来源于stack exchange，提问作者H.Gndgn