如何防范Chrome扩展程序引发的API滥用问题？

我开发Chrome扩展时也碰到过类似的API滥用问题，给你几个实用的防范思路：

1. 给Client ID加服务端合法性校验 #

别只校验Client ID存在就行，得在服务端维护每个ID的完整生命周期：

• 扩展安装生成ID后，先向服务端发起注册请求，服务端记录这个ID的创建时间、首次请求的IP/UA，以及关联的扩展签名信息（如果是Chrome Web Store发布的，服务端可以验证请求来源的扩展ID是否是你发布的）。
• 给每个ID设请求频率限制，比如每分钟最多10次请求，超了直接拦截，从根源上限制滥用。

2. 用请求签名替代裸Client ID #

每次请求除了带Client ID，再额外加一个服务端能验证的签名：

• 扩展里内置一个只有你和服务端知道的密钥（可以做代码混淆，别明文写死），结合请求的时间戳、接口路径、参数生成HMAC签名，服务端收到请求后用同样的逻辑重新生成签名对比，不一致就拒绝。
• 时间戳是用来防重放攻击的，服务端要校验时间戳和当前时间差不超过5分钟，过期的请求直接打回。
  简单的签名生成逻辑示例：

  // 扩展端生成签名
  async function generateSignature(clientId, timestamp, path, params) {
    const secret = '你和服务端约定的密钥';
    const payload = `${clientId}${timestamp}${path}${JSON.stringify(params)}`;
    const hashBuffer = await crypto.subtle.digest('SHA-256', new TextEncoder().encode(payload));
    return Array.from(new Uint8Array(hashBuffer))
      .map(b => b.toString(16).padStart(2, '0'))
      .join('');
  }
  

3. 绑定请求到你的扩展ID #

Chrome扩展从后台页面发起的请求会自动带chrome-extension://[你的扩展ID]的Referer头，服务端直接校验这个Referer是否是你发布的扩展ID，不是就拒绝。
如果是Web Store上架的扩展，还可以用Chrome的许可证验证API，让扩展把许可证信息传给服务端，验证这个许可证对应的扩展ID是否合法，确保请求来自真实安装的扩展。

4. 把永久Client ID换成短期令牌 #

别用永久有效的Client ID，改用短期访问令牌：

• 扩展启动时用Client ID向服务端请求一个15-30分钟有效期的令牌，后续所有请求都带这个令牌。服务端维护令牌的有效期和关联的Client ID，过期了就得重新获取。
• 还可以设置令牌滑动过期，每次请求成功就刷新令牌有效期，或者让令牌一次性使用，进一步降低伪造后滥用的风险。

5. 强化Client ID的存储和传输安全 #

• 别把Client ID存在localStorage，改用Chrome自带的chrome.storage.local或者chrome.storage.sync，虽然开发者工具还是能看，但把生成和携带ID的逻辑放在后台页面（background script）里，不和页面上下文接触，减少暴露的可能。
• 所有API请求都通过后台页面代理，不让内容脚本直接发请求，降低请求参数被抓包的概率。

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