如何隐藏HTTP请求中的重要凭证？JS SDK密钥暴露问题求解

我们开发了一款可集成到客户网站的JavaScript SDK，初始化方式如下：

initializeMethod.init({
      PROJECT_ID: 'XXXXX-XXXX-XXXXX',
      API_KEY: 'XXXX-XXX-XXXX',
      email: '',
      mobile: '',
      firstName: '',
      lastName: ''
    });

当前我们会把PROJECT_ID和API_KEY放到每个HTTP请求的请求头里，虽然运行正常，但存在严重安全问题：这些凭证会完全暴露给所有用户，任何人都能拿去在自己的应用里初始化SDK并执行任意操作，这是我们要避免的。我们知道前端无法直接隐藏这些敏感数据，现在需要可行的替代方案，而且首个请求就必须验证凭证有效性，还不能用代理服务器。

可行方案 #

1. 短期临时Token替代长期API_KEY #

• 操作流程：让客户用自己的后端服务，拿着长期的PROJECT_ID和API_KEY调用你们的接口，换取一个短期、限权、绑定域名的临时Token。前端初始化SDK时，不再传API_KEY，只传PROJECT_ID和这个临时Token，同时SDK自动带上当前页面的域名。
• 验证逻辑：你们的服务收到请求后，先检查Token的有效期、绑定域名是否匹配，以及Token本身的合法性，全部通过再处理请求。
• 好处：就算Token被泄露，有效期短、权限有限，造成的危害可控；首个请求就能用Token完成验证，完全符合要求。

2. 请求签名验证机制 #

• 操作流程：
  1. 先让客户在你们的控制台配置一个专属的签名密钥，这个密钥只存在客户后端和你们的服务端，绝不传到前端。
  2. 客户后端给前端生成签名串：把PROJECT_ID、当前时间戳、随机字符串凑在一起，用HMAC-SHA256算法+签名密钥加密生成签名。
  3. 前端初始化SDK时，传入PROJECT_ID、时间戳、随机串、签名串，不用传API_KEY。
• 验证逻辑：你们的服务收到请求后，用相同的密钥和算法，重新计算签名并和前端传来的比对；同时校验时间戳是否在5分钟内，防止重放攻击。
• 好处：API_KEY全程不碰前端，彻底杜绝暴露风险；首个请求就能完成签名验证，满足业务要求。

3. 绑定域名白名单的凭证策略 #

• 操作流程：
  1. 在客户控制台里，让客户预先设置允许调用SDK的域名白名单，比如https://their-website.com。
  2. 前端初始化SDK时只传PROJECT_ID，SDK自动收集当前页面的域名。
  3. 首个请求把PROJECT_ID和域名一起发给你们的服务，验证通过后返回一个临时访问凭证，后续请求用这个凭证。
• 额外加固：如果怕域名被伪造，可以让客户在域名的DNS记录里加一条指定的TXT记录，你们的服务验证域名时先查这条记录，确保域名是客户真实拥有的。
• 好处：前端完全不用处理敏感密钥，从根源上避免暴露；首个请求就能完成域名验证，符合要求。

4. 匿名初始化+后端身份绑定 #

• 操作流程：
  1. SDK初始化时不用传任何敏感凭证，以匿名身份发首个请求，你们的服务返回一个匿名会话ID。
  2. 客户后端在用户登录完成后，用自己的PROJECT_ID和API_KEY调用你们的接口，把用户ID和这个匿名会话ID绑定。
  3. 后续SDK请求带上会话ID，你们的服务验证会话是否已绑定合法客户身份，再处理请求。
• 好处：前端全程碰不到敏感数据；首个请求先建立会话，后续通过后端完成身份绑定，适配业务流程。

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