如何防止用户通过修改表单提交的对象ID篡改预期操作？——问卷提交场景的服务端控制方案咨询

这是个非常常见的后端安全问题，我来分享几个经过实践验证的服务端控制方案，不管是你遇到的问卷提交场景，还是其他需要指定操作目标的通用场景都适用：

一、针对问卷提交场景的具体控制方案 #

• 服务端提前绑定用户与可作答问卷的关系
  别完全信任前端传的问卷ID！用户进入问卷页面时，服务端就应该把该用户有权作答的问卷ID存入会话（Session），或者生成一个关联的临时凭证。当用户提交答案时，先做第一步校验：前端传的问卷ID是否在当前用户的可作答列表里？不在就直接返回错误，拒绝处理请求。
• 用加密签名替代明文问卷ID
  前端渲染问卷页面时，不要直接输出明文的问卷ID，而是给每个问卷ID生成一个加密签名（比如用HMAC-SHA256算法，结合服务端的密钥和问卷ID生成签名，把问卷ID.签名作为前端要传输的标识）。服务端收到提交请求后，先拆分出ID和签名，用相同的密钥重新计算签名，只有签名匹配的ID才会被处理——用户就算篡改了ID，签名肯定对不上，请求直接被打回。
• 一次性专属凭证机制
  如果问卷是只能作答一次的类型，可以在用户进入问卷时生成一个唯一的一次性token，把token和问卷ID绑定后存入服务端。用户提交答案时必须携带这个token，服务端校验token和问卷ID的绑定关系，而且token只能用一次，用完就失效。就算用户拿到了其他问卷的token，也没法重复利用。

二、通用场景下防止篡改操作目标ID的方案 #

这些方案适用于所有需要通过ID指定操作目标的场景（比如修改文章、删除评论、编辑订单等）：

• 权限校验永远是第一步
  不管前端传什么ID，服务端在执行操作前必须先校验：当前用户是否有权限操作这个ID对应的对象？比如要修改某篇文章，先查这篇文章的作者是不是当前用户，或者用户有没有编辑权限——而不是看ID合法就直接执行操作。
• 尽量不要依赖前端传递关键标识
  能从服务端上下文获取的信息，就别让前端传。比如用户正在编辑自己的订单，订单ID可以直接从用户的会话或者登录状态里关联获取，而不是让前端把订单ID传到后端。
• 用不可预测的标识符替代自增ID
  别用容易被猜测的自增ID（比如1、2、3）作为前端传输的标识，改用UUID或者随机生成的长字符串。虽然这不能彻底阻止篡改，但能大幅增加用户猜测或伪造有效ID的难度。
• 给请求关键参数加签名
  对请求里的关键参数（包括目标ID）进行签名，前端提交时把签名一起传过来。服务端收到请求后，用相同的算法和密钥重新计算签名，只有签名完全匹配才处理请求——用户只要修改任何参数，签名就会失效，请求直接被拒绝。
• 会话绑定操作目标
  用户进入操作页面（比如编辑文章页）时，把要操作的对象ID存入用户的Session。当用户提交操作请求时，服务端对比前端传的ID和Session里的ID是否一致，不一致就拒绝请求。这样就算用户篡改了前端的ID，也过不了这一关。

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