如何防范前端公开API密钥被盗取及非法使用？

首先先纠正一个常见认知偏差：

类似Stripe publishable key这类设计给前端用的公钥，从产品架构设计之初就默认是会暴露在前端静态资源、网络请求里的，根本做不到100%不被别人拿到。所有防护的核心目标从来不是"不让人偷到密钥"，而是"就算被人拿到了，也没法超出授权范围乱用，就算真的被滥用也能快速止损，不会造成实际损失"。

域名白名单确实不是万能的，单靠自己在业务层写个Referer/Origin头校验，攻击者随便在服务端构造请求头就能绕过去，但这不代表白名单没用，要配合多层防护机制一起用，具体可以按下面的优先级落地：

• 首先卡死公钥的权限边界，这是最核心的防线
  给前端公钥分配权限的时候严格遵循最小必要原则，绝对不要给它开放任何敏感操作权限。拿Stripe的公钥举例，官方本身就锁死了它的能力：只能用来渲染支付组件、生成一次性支付token、提交非敏感的用户标识，既不能直接发起扣款、不能查询账户交易数据、不能修改用户的签约状态，就算被人扒走，最多也就是在别的页面嵌一个指向你账户的支付入口，根本碰不到你的核心资产。如果是自研API的公私钥体系，一定要记住：前端公钥能调用的所有接口，都要满足"就算被陌生人随便调，也不会造成资金损失、不会生成脏数据、不会泄露用户隐私"的标准。
• 正确配置多层来源校验，不要用单点白名单凑数
  不要自己在业务后端写个简单的请求头判断就当白名单用了，要做两层校验：第一层是API服务提供方控制台（比如Stripe后台）自带的账户级域名白名单，这层校验是跑在服务商边缘节点上的，和你的账户权限强绑定，攻击者自己构造请求头根本绕不开；第二层是自己业务侧补充的来源校验，同时要注意，来源校验永远不能当唯一的防护手段。
• 给公钥请求绑定用户态的短期临时凭证
  不要让公钥本身成为调用接口的唯一凭证。正确的调用流程应该是：用户进入你的页面、通过登录/访客身份校验后，你的后端先判断当前用户状态合法，再签发一个有效期只有几分钟、和当前用户ID、会话IP、访问场景绑定的签名token，前端发起请求的时候必须同时带上公钥和这个临时token，API侧同时校验两个凭证的合法性。攻击者就算偷走了你的公钥，拿不到你后端给合法用户签发的临时token，根本调不通任何有实际作用的接口。
  针对别人把你的公钥拿到钓鱼网站上用的场景，你还可以在签发临时token前，要求前端把当前页面的window.location.origin值作为参数传给后端，不在你自有域名列表里的请求一律不发token，钓鱼站就算嵌了你的公钥，也走不通完整流程。
• 配置异常监控和快速熔断机制
  给公钥的调用行为配置基础的监控规则：比如单IP短时间调用量突增、出现你业务覆盖区域外的IP请求、出现非业务预期的接口调用、参数不符合常规业务逻辑的时候，立刻触发告警，必要时自动拦截异常来源的请求。另外前端公钥的轮换成本非常低，真的发现大规模滥用，直接在控制台作废旧公钥、下发新公钥就行，不需要改后端核心逻辑，几分钟就能完成止损。
• 绝对守住私钥的安全红线
  所有需要私钥的操作100%放在后端服务环境完成，永远不要把私钥写到前端代码、打包到前端静态资源里，不要为了省事儿用私钥直接调前端接口。要明确：前端公钥泄露从来不算严重安全事件，私钥漏了才是会出大问题的。

内容的提问来源于stack exchange，提问作者Dimitri Borgers