Angular 5.0应用REST API安全咨询：Payload篡改与非法Postman请求问题

嘿，这个问题戳中了很多开发者在基础Token认证之后的安全盲区——Token只是身份凭证，但没法防止请求内容被篡改或重放。结合你的Angular+REST API场景，咱们可以从这些关键环节补全安全措施：

1. 给请求加签名，确保内容未被篡改 #

这是防篡改的核心手段：让前端对请求的核心内容（Payload、请求时间戳、Token）用**对称加密算法（比如HMAC-SHA256）**生成签名，然后把签名和时间戳一起放到请求头里。

具体流程：

• 前端侧：
  1. 把要发送的Payload转成JSON字符串，加上当前的时间戳（精确到秒即可）、用户的AccessToken
  2. 用后端预先和前端约定好的密钥（仅前后端知晓，绝对不能暴露到前端代码外），对拼接后的内容做HMAC-SHA256哈希，得到签名值
  3. 把签名（比如X-Request-Sign）和时间戳（X-Request-Timestamp）放到请求头，和Payload一起发送
• 后端侧：
  1. 先校验时间戳是否在有效窗口内（比如5分钟），防止攻击者用很久之前的请求重放
  2. 用同样的密钥、同样的拼接规则，重新计算签名值
  3. 对比前端传来的签名和后端计算的签名，不一致就直接拒绝请求

这样一来，哪怕攻击者拿到了Token和原始Payload，只要不知道密钥，篡改任何内容（包括Payload、时间戳）都会导致签名不匹配，API就能直接拦截。

2. 强制HTTPS传输，杜绝明文泄露 #

你提到Chrome能看到Payload，首先要确保你的API和前端都用HTTPS部署：

• HTTPS会对整个请求过程（包括Token、Payload、请求头）做加密，中间人抓包只能拿到密文，无法直接获取敏感内容
• 后端要配置禁止HTTP请求，所有HTTP请求直接重定向到HTTPS，或者返回403拒绝

3. 强化Token的安全性，降低被盗后的危害 #

Token本身的安全也得升级：

• 缩短AccessToken有效期：比如设置15分钟有效期，配合RefreshToken获取新的AccessToken。就算Token被盗，可用时间窗口很短，攻击者来不及做太多操作
• 给Token绑定设备标识：生成Token时，把用户的设备信息（比如User-Agent的哈希、IP的模糊哈希）放到Token的Payload里，后端校验请求时，对比当前请求的设备信息和Token里的是否一致。这样就算Token被拿到，换个设备也用不了
• 用JWT的话要做签名验证：如果用的是JWT，一定要用HS256或RS256签名，后端必须验证签名的有效性，防止Token被篡改。另外，别把敏感信息放到JWT的Payload里——因为Payload是Base64编码的，能直接解码，只能放非敏感的身份标识

4. 后端不要完全信任前端，做好权限和数据校验 #

前端传来的任何内容都可能被篡改，后端必须做二次校验：

• 权限校验：比如用户提交修改订单的请求，后端要先查这个订单是否属于当前用户，用户有没有修改该订单的权限（比如是不是订单的创建人）
• 数据合法性校验：对Payload里的每个字段做校验，比如金额不能是负数、日期格式要合法、必填字段不能缺失，防止恶意输入破坏业务逻辑
• 实现幂等性：对于创建类的请求（比如提交订单），前端生成一个唯一的请求ID（比如UUID），后端记录这个ID，同一个ID只处理一次。这样就算攻击者重复发送请求，也不会创建多个重复的订单

5. 限制请求来源，拦截非法客户端 #

• 配置严格的CORS策略：后端只允许你的Angular前端域名跨域请求，拒绝其他域名的请求（比如Postman的域名）
• 校验Referer/Origin头：虽然这两个头可以被伪造，但能挡住大部分非专业的攻击者。后端检查请求的Origin或Referer是否是你的前端域名，不是就拒绝

6. 日志与异常监控 #

后端要记录所有异常请求：比如签名验证失败、Token设备不匹配、重复请求ID、权限校验失败等。一旦发现短时间内大量异常请求，就临时锁定用户账号或者触发告警，及时处理安全事件

你目前遗漏的关键安全措施总结 #

1. 请求内容的签名验证（防篡改、防重放）
2. 强制HTTPS传输（防明文泄露）
3. Token的设备绑定与短有效期（降低被盗危害）
4. 后端端到端的权限与数据校验（不信任前端）
5. 请求幂等性处理（防重复提交）

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