服务端开发博客 | 后端架构 · 高并发 · 性能优化 · 微服务实战 👋🏼

引言 去年我们开放了一组 API 给合作方调用。上线两周，安全团队做了一次渗透测试，结果三连暴击： 篡改：合作方调"创建订单"接口，金额参数被中间人从 amount=9900 改成 amount=1，9900 的货一块钱拿走。HTTPS？用的是自建代理抓包改的，HTTPS 只防链路嗅探，不防应用层改包 重放：攻击者抓到一条"发放优惠券"的成功请求，原封不动重放了 873 次，券池被薅干 泄漏：合作方把 secretKey 明文写在前端 JS 里，被 F12 一秒扒走，拿着 key 想签什么签什么 三个问题，一个比一个疼。我们的修复方案叫 timestamp + nonce + sign 三合一签名：时间戳防重放窗口、随机数防重放、HMAC-SHA256 签名防篡改和防 key 泄漏。上线后渗透复测三项全部通过。 这篇文章把整套方案从需求拆解到代码实现完整讲一遍，覆盖： 三合一设计的底层逻辑：每个字段为什么必须有、HTTPS 为什么不够 客户端签名算法：参数排序 → 拼接 → HMAC-SHA256 → Base64 服务端校验全流程：时间窗口 → nonce 去重 → 重算签名比....

前言 在当今互联网应用中，API 接口安全面临着严峻挑战： 中间人攻击：攻击者截获并篡改请求参数 重放攻击：攻击者重复发送已捕获的请求 参数篡改：恶意修改请求参数获取非法利益 非法调用：未授权的第三方调用敏感接口 这些安全威胁可能导致用户数据泄露、资金损失等严重后果。本文将详细介绍如何使用 Spring Boot 实现基于 HMAC-SHA256 的请求签名验证机制，有效防止中间人攻击和参数篡改。 一、API 安全威胁分析 1. 常见攻击类型 攻击类型攻击原理危害程度防护难度 中间人攻击截获并篡改通信内容高中 重放攻击重复发送有效请求中低 参数篡改修改请求参数高中 非法调用未授权访问接口中低 数据泄露截获敏感数据高高 2. 传统防护方案的局限性 方案优点缺点适用场景 HTTPS加密传输无法防止参数篡改基础安全 Token 认证身份验证无法防止参数篡改用户认证 IP 白名单简单直接无法应对动态 IP内部服务 签名验证防篡改、防重放实现复杂关键接口 3. 签名验证的优势 防篡改：任何参数修改都会导致签名验证失败 防重放：通过时间戳和随机数防止重复请求 身份验证....