生产构建产物暴露环境变量与服务密钥的安全处理方案咨询

首先明确核心前提：所有运行在用户浏览器侧的代码、数据、请求内容，对用户都是完全可见的。不存在任何前端侧的技术手段能彻底隐藏密钥——不管你是把密钥打包在JS文件里、还是运行时从后端接口拉取、还是存在浏览器内存里，只要密钥需要由浏览器直接携带发起对第三方服务的请求，用户通过扒构建包、F12看网络面板、打JS断点的方式，一定能拿到明文密钥，在前端侧做加密、混淆、环境变量拆分全是无效操作。

针对你遇到的场景，按优先级选可落地的解决方案即可：

• 优先选后端代理模式，这是唯一能100%杜绝密钥泄露的方案
  所有需要携带该服务密钥的第三方API请求，不要让前端直接发起，全部转发到你自己的业务后端：前端只传业务必要参数到自有后端接口，由后端在服务端读取存储在服务端环境变量里的密钥，拼接后发起对第三方服务的请求，拿到响应后再把前端需要的业务数据返回。
  针对高频请求场景，直接在代理层加缓存即可：对相同参数的第三方接口响应，按照第三方接口本身的缓存有效期，在后端做内存缓存或者Redis缓存，既能减少第三方接口的调用频次、节省服务配额成本，也能抵消多一层代理带来的耗时损耗，不会影响前端响应速度。
  这种模式下密钥全程只在服务端流转，完全不触达用户侧，不管用户扒生产包、抓前端请求、还是调试前端代码，都拿不到密钥值，从根源解决泄露问题。
• 如果第三方服务本身提供前端安全鉴权能力，可使用官方的临时凭证方案
  绝大多数面向前端场景提供服务的第三方平台（比如地图服务、公共数据查询服务、云存储服务），都不会要求前端直接携带长期主密钥调用，一般会提供「域名白名单+临时签名凭证」的鉴权模式：你可以在第三方服务控制台把自己的业务域名加入访问白名单，后端用存储在服务端的长期主密钥，生成有短有效期（通常10分钟到2小时不等）、绑定当前用户访问权限、限制可调用接口范围的临时签名token返回给前端，前端用这个临时token直接调用第三方接口。
  这种模式就算临时token被用户抓包拿到，首先过了有效期就会直接失效，其次非白名单域名发起的请求会被第三方服务直接拦截，就算出现泄露也不会造成大额资损、服务被恶意滥用的问题。

以下操作全是无效方案，不要浪费时间做：

• 不要试图在构建阶段对环境变量里的密钥做加密、混淆：不管你加密逻辑写的多复杂，前端运行时总要解密才能拿到密钥使用，解密逻辑和密文最终都存在JS包里，打个运行时断点就能直接拿到明文密钥。
• 不要把密钥从构建包移到运行时接口返回就觉得安全了：只要前端拿到密钥后直接发起第三方请求，用户打开F12看网络请求的头、参数，直接就能看到明文密钥，和打包在JS里没有任何本质区别。
• 不要指望代码压缩、混淆能隐藏密钥：混淆后的代码只是可读性差，不是不可读，通过网络请求断点、关键字搜索，几秒钟就能定位到密钥的明文值。

如果对接的第三方服务既不支持临时签名鉴权、也不支持域名白名单限制，没有任何取巧的解决方案，必须走后端代理转发——毕竟只要用户浏览器能拿到密钥，就等于所有访问你网站的人都能拿到这个密钥，别人可以直接盗用你的密钥爬取数据、刷爆你的服务配额，产生不必要的损失。

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