调用需携带API-key的第三方API时是否需要搭建后端中转服务？

首先明确核心原则：任何会产生资金风险、数据安全风险的API-key，绝对不能直接放在前端代码里。
所有前端代码、请求逻辑对终端用户是完全透明的：不管你把key藏在.env配置、打包产物的哪个角落，用户只要打开浏览器开发者工具，要么直接从网络请求头里抓到明文key，要么断点调试下几秒钟就能定位到key的值，根本不存在“藏住”的可能。key被盗后，轻则被人盗刷接口产生超额账单、爬取你付费购买的接口数据，重则如果接口有写入、管理权限，可能直接篡改你的业务资源，造成不可逆的损失。

两种方案的适用场景：

• 优先选择自建后端中转（Spring Boot、Node.js、各类Serverless函数都可以实现）
  这种方案的优势非常明确：
  • API-key只存放在后端服务的环境变量中，全程不触达前端，从根源上杜绝key泄露的可能
  • 你可以在中转层统一做权限校验、流量控制、参数合法性校验，避免恶意用户构造非法请求触发外部接口的异常计费、限流
  • 可以在中转层做数据裁剪、缓存，不用把外部接口返回的冗余数据全量传给前端，还能降低重复请求的耗时
  • 天然解决外部API的跨域限制问题，不用额外配置开发/生产环境代理
• 仅当满足以下条件时，才可以考虑前端直连：
  你使用的是API服务商官方提供的前端专属公钥，这类key本身就是设计为公开暴露在前端使用的，服务商通常会给这类key提供完备的风险限制能力，就算被拿到也无法造成实质损失。

先提前说清楚：只要key出现在前端环境，就没有100%防窃取的方案，所有手段都只是提高窃取门槛、降低泄露后的损失，做不到绝对安全。如果key泄露的后果你承担不起，老老实实走后端中转，不要抱侥幸心理。
具体可落地的防护手段包括：

• 核心前提：必须使用服务商提供的前端受限key，给key配置最严格的权限规则
  • 配置域名白名单：仅允许你自己的业务域名发起的请求被接口认可，其他域名就算拿到key也无法正常调用
  • 权限最小化：只给这个key开放前端业务必须用到的接口权限，绝对不要开启写入、删除、账号管理类的高风险权限
  • 配置额度阈值：给这个key设置日/月调用上限、单IP调用频率限制，就算key被盗，损失也会被控制在你预设的范围内
• 避免明文key进入代码仓库
  不要把key硬编码在业务代码里，通过构建工具的环境变量能力在构建阶段注入（比如React项目中使用REACT_APP_前缀的环境变量），避免明文key被提交到代码仓库造成泄露。注意这一步只能防仓库泄露，防不了终端用户从前端产物里拿到key。
• 适当做混淆提高窃取成本
  • 不要在代码里用固定常量直接存储完整key，可以把key拆成多段字符串，运行时动态拼接，或者做简单的编码（比如Base64），运行时再解码使用
  • 对前端打包产物做压缩、变量名混淆、调试信息剥离，提高静态分析代码扒取key的成本
    要明确：这些手段只能防完全不懂技术的普通用户，有基础前端逆向能力的人花几分钟就能绕过，不要把这个当成核心防护手段。
• 请求层增加校验逻辑
  • 尽量不要每次请求都传固定不变的key，可以配合时间戳、请求参数生成动态签名，服务端校验签名合法性，就算签名被抓包，也会在短时间内过期失效
  • 配合开启接口的防盗链、跨域来源校验，拦截非本站点发起的恶意请求

补充提醒：如果你的项目是纯静态站点、不想维护单独的后端服务，也可以用云厂商的边缘函数、API网关来做中转层，成本极低，同样能达到key不暴露给前端的效果，比在前端堆防护手段靠谱得多。

内容的提问来源于stack exchange，提问作者Noah Kruger