如何拒绝非授权来源的HTTP/HTTPS请求？API安全防护咨询

针对你描述的场景——第三方无需认证即可调用customer-backend.com/use-my-api获取数据，以下是几种可行的解决方案，均避开不可靠的host头验证：

1. 前端动态签名验证（适配无登录场景） #

这是无登录环境下最直接的防伪造方案，核心是让前端和后端约定专属密钥，生成仅当前请求有效的签名：

• 客户前端与后端共享一个仅双方知晓的密钥（secret），前端可通过代码混淆隐藏该密钥
• 前端每次发起请求时：
  1. 生成当前时间戳timestamp和随机字符串nonce（防止重放攻击）
  2. 用HMAC-SHA256算法，将timestamp + nonce + secret混合生成signature
  3. 把timestamp、nonce、signature作为参数或请求头传给后端
• 客户后端验证逻辑：
  • 检查timestamp是否在有效时间窗口内（比如5分钟），超时直接拒绝
  • 检查nonce是否已被使用过（用Redis存储已验证的nonce，过期时间和时间窗口一致）
  • 用相同的secret、timestamp、nonce重新计算签名，与请求中的signature对比，一致则放行
• 优势：第三方不知道secret就无法生成有效签名，无法伪造请求；无需大改现有架构
• 局限性：前端密钥存在被逆向破解的风险，需配合代码混淆降低泄露概率

2. 同源验证+Referer辅助检查 #

虽然Referer头可被篡改，但配合签名能大幅提高攻击门槛：

• 客户后端检查请求的Referer头是否以customer.com开头，同时验证Origin头是否为customer.com
• 注意：HTTPS环境下部分浏览器可能不发送完整Referer，因此该方法仅作为签名验证的补充，不能单独使用

3. 架构调整：让前端直接对接你的API（更安全的长期方案） #

通过中间层或临时凭证机制，绕过客户后端的中转，同时保护api-key：

方案A：边缘计算服务代理 #

• 使用边缘计算服务作为中转层，在服务中配置你的api-key，并设置CORS规则仅允许customer.com跨域请求
• 前端直接请求边缘服务的接口，边缘服务验证请求来源后，再转发到my-api.com/getData

方案B：短期临时凭证机制 #

• 前端先请求客户后端的get-temp-token接口，后端验证请求来源（Referer+Origin）后，颁发一个10分钟内有效的临时token
• 前端用该token请求你的API，你的API与客户后端约定验证逻辑，确认token有效性后返回数据
• 优势：彻底避免客户后端成为攻击入口，api-key仅在边缘服务或客户后端内部流转，安全性更高
• 局限性：需要额外部署边缘服务或开发临时凭证生成/验证逻辑

4. IP白名单（仅适用于固定IP场景） #

如果客户的访客来源IP是固定的（比如企业内网用户），可在客户后端配置IP白名单，仅允许指定IP段访问use-my-api接口。但公网普通访客场景下不适用，因为访客IP不固定。

内容的提问来源于stack exchange，提问作者Çağrı Eroğlu