HTTPS、加密与签名：确保API接口请求防篡改的完整方案

[wapicn99]

 

前言

API接口通信中，数据裸奔就等于把家门钥匙放门口。篡改请求参数、劫持返回内容、重放攻击等都是常见威胁。作为一个重度使用挖数据API的开发者，我想结合它的实践，拆解出一套防篡改完整方案。

 

第一层：HTTPS，但不止于HTTPS

挖数据全站强制HTTPS，仅支持TLS1.2+，禁用了不安全的加密套件。然而HTTPS只保证了传输层加密和服务器身份认证，对于应用层伪造请求，无法防护。如果黑客获取了你的API Key，他完全可以通过HTTPS合法地发起恶意请求。因此，传输加密只是地基，我们需要在应用层再加两道锁。

 

第二层：请求签名——保证请求体的完整与身份

挖数据采用的AK/SK签名机制，是防篡改的核心。每次请求，客户端需构建一个规范字符串，包含HTTP方法、URI路径、查询参数、时间戳、随机Nonce和请求体，用SK进行HMAC-SHA256哈希。服务端收到请求后，用相同的规则计算签名，对比是否一致。哪怕攻击者在HTTPS通道内替换了一个参数，签名校验就会失败。时间戳和Nonce的组合，也使得重放攻击彻底失效。具体实现时，前端千万不要参与签名，必须由后端生成，否则SK就会暴露在客户端，签名形同虚设。

 

第三层：响应验签——双向防篡改

很多人只防请求，不防响应。如果API返回的数据被中间节点篡改，比如将风险评分“0.9”改成“0.1”，业务就崩溃了。挖数据支持响应签名：在响应头X-Response-Signature中返回对响应体计算出的签名。我们客户端的做法是，预先约定好响应的签名算法，收到数据后，用已知的SK再次计算签名，与之对比。一旦不匹配，立即丢弃并告警。这在金融级场景中特别关键，保证了数据的端到端可信。

 

第四层：加密敏感字段，双重保险

对于极敏感数据，挖数据在返回中不仅脱敏，还提供了可选的字段级加密。利用我们预先上传的公钥，对法人身份证号等超敏字段进行RSA加密，只有持有私钥的我们才能解密。即使API日志被第三方窥探，看到的也是一堆乱码。这满足了一些强合规场景的需求，把数据自决权完全交给了客户。

 

第五层：证书固定（SSL Pinning）

对于我们的移动端App，为了防止中间人通过伪造证书截获HTTPS流量，我们还做了证书固定。把挖数据API域名的合法证书公钥哈希值预置在App中，握手时只信任该证书，即使设备被安装了恶意根证书也无法劫持。虽然这会带来证书更换时的更新成本，但在高安全场景下值得。

 

总结

从HTTPS到请求签名、响应验签，再到字段加密和证书固定，这套组合拳构建了一个完整的数据防篡改方案。挖数据作为API提供方，把这些能力标准化输出，让我们开发者能轻松集成，值得写入技术选型手册。

 

#挖数据 #API防篡改 #请求签名 #响应验签 #加密方案