向资源服务器发起JWT请求时，是否存在Payload篡改风险及防护方法？

Great question—this is a common point of confusion when working with JWT, so let’s unpack it step by step.

1. 会不会发生Payload篡改？ #

首先要明确两个核心概念：JWT自身的Payload和请求中附带的独立Payload（比如POST JSON body、URL查询参数、XML数据等）：

• 对于JWT自身的Payload：它是Base64编码（不是加密，所以能被解码读取），但因为JWT带有签名部分，任何人篡改Payload后，服务器验证签名时都会失败——因为签名是基于Header和Payload生成的，篡改后重新计算的签名和原签名完全不匹配，服务器会直接拒绝这个JWT。所以JWT的Payload是无法被篡改而不被检测的。
• 对于请求中独立于JWT的Payload：这部分是完全可能被篡改的！因为它们没有被JWT的签名机制保护，中间人可以在传输过程中修改这些数据（比如把POST body里的amount: 10改成amount: 1000），如果服务器没有额外校验，就会被蒙骗。

2. 如何防护独立Payload免遭篡改？ #

这里有几个实用的方案，你可以根据业务场景选择：

• 把敏感Payload数据移入JWT的Payload中：这是最直接的方法。比如用户的操作权限、交易金额、目标ID这类敏感数据，别放在请求参数或body里，直接塞进JWT的Payload。这样这些数据就被JWT的签名保护了，篡改后服务器会立刻检测到签名无效。
• 给独立Payload单独添加签名：如果因为数据太大或者业务原因，必须把数据放在JWT外面，那可以用和JWT相同的密钥（比如HMAC密钥）对Payload生成签名。举个简单例子：
  • 客户端把POST body的JSON字符串用HMAC-SHA256算法，结合密钥生成签名，然后把签名放在自定义HTTP头（比如X-Payload-Signature）里。
  • 服务器收到请求后，取出body和签名，用同样的密钥和算法重新计算签名，对比两个签名是否一致。如果不一致，说明Payload被篡改了，直接拒绝请求。
• 强制使用HTTPS传输：这是基础中的基础。HTTPS不仅能加密传输内容防止中间人窃听，还能通过SSL/TLS的完整性校验防止篡改——中间人篡改请求内容后，SSL/TLS的消息认证码会失效，服务器会直接断开连接，不会处理篡改后的请求。注意：HTTPS只能防护传输过程中的篡改，无法防止服务器端内部的篡改，所以还是要结合上面的签名方案。
• 避免在URL查询参数中存放敏感Payload：URL参数会被浏览器、代理服务器、日志系统记录，而且如果不小心用了HTTP，会明文传输，非常容易被截获篡改。敏感数据尽量放在POST body里，并且配合HTTPS和签名。
• 对整个请求进行完整性校验：如果需要更严格的防护，可以把整个请求的关键部分（HTTP方法、路径、Payload、JWT的部分内容等）都纳入签名范围，生成一个全局的请求签名。这样任何部分被篡改，服务器都能检测到。

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