如何验证API请求来自Chrome扩展并限制专属访问？

你提到的自定义头方案安全性极低——攻击者只需手动在请求中添加该头就能绕过验证，完全起不到限制作用。下面是几个更可靠的实现方式，均无需依赖数据库：

1. 验证请求的Origin/Referer头（基于扩展ID） #

Chrome扩展发起的请求会自动携带Origin或Referer头，格式为chrome-extension://<你的扩展ID>，打包发布后的扩展ID是固定唯一的。

• 实现方式：在API端将你的扩展ID硬编码到白名单配置中，每次请求时检查Origin或Referer是否匹配白名单内的ID。
• 优势：浏览器自动填充这些头，正常场景下无法被篡改（除非用户使用恶意代理工具，但这属于极端情况），实现简单且安全性较高。
• 注意事项：开发阶段的扩展ID是临时的，要区分开发和生产环境的白名单配置；若允许用户加载解压后的开发版扩展，该方法的有效性会降低。

2. 请求签名验证（预共享密钥） #

通过预共享密钥对请求进行签名，API端验证签名合法性：

• 实现步骤：
  1. 在扩展和API端硬编码同一个密钥（需对扩展代码做混淆处理，降低密钥被反编译获取的风险）。
  2. 扩展发起请求时，对请求路径、时间戳、请求体哈希等关键参数结合密钥，用HMAC算法（如HMAC-SHA256）生成签名，将签名和时间戳放在请求头（比如X-Request-Signature和X-Request-Timestamp）中。
  3. API端拿到请求后，用相同参数和密钥重新计算签名，对比是否一致；同时检查时间戳是否在有效范围内（比如5分钟内），防止重放攻击。
• 优势：即使攻击者伪造请求头，没有密钥也无法生成合法签名，安全性更高。
• 注意事项：密钥需做好保密，扩展代码必须混淆；时间戳的时区要统一，避免验证失败。

3. 扩展ID+签名双重验证 #

将前两种方案结合，进一步提升安全性：

• 先验证请求的Origin是否属于合法扩展ID，确保请求来自可信的扩展环境；
• 再验证请求签名，确保请求内容未被篡改且来自持有密钥的合法客户端。

为什么不推荐单独使用自定义头 #

自定义请求头（比如X-Extension-Source）没有任何内置安全机制，攻击者可以轻松通过Postman、curl等工具添加该头，完全无法限制非扩展来源的请求，仅能作为辅助标识，不能单独作为验证手段。

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