如何保障网页游戏POST/PUT路由安全 防止用户恶意篡改金币数据

你的担心完全成立。哪怕你已经加了基础JWT鉴权，如果接口设计成直接接收前端传来的gold数值写入数据库，攻击者根本不需要破解系统，只要登录自己的账号，抓个包构造PUT请求把gold字段改成任意数字，就能随便刷金币。
你现在实现的JWT鉴权，只能解决「这个请求是哪个已登录用户发的」的身份识别问题，完全管不了「这个用户提交的操作是不是符合游戏规则」的业务合法性问题，这是两层完全不同的校验逻辑，不能混为一谈。

• 从接口设计根源上堵死篡改可能，永远不要信任前端传的计算结果
  涉及金币变动的接口，绝对不要把gold这类最终数值作为入参让前端传。前端的权限仅限于上报「用户触发了什么具体操作」，比如通关、解锁成就、领每日奖励，所有金币增减的规则计算、合法性校验100%放在服务端跑。举个实际的例子：用户打赢第三关按规则得50金币，前端只需要发POST /api/game/action/complete，请求体只带{levelId: 3}就行，剩下的全交给服务端校验：
  1. 校验这个用户是否真的达成了第三关通关条件（结合服务端记录的游戏状态、操作时序判断，不是前端说通关就算通关）
  2. 校验第三关的通关奖励有没有被领取过
  3. 按配置的规则算出应发的金币数
     所有校验通过后，服务端自己读取数据库里该用户当前的gold值，加上应发的50再写回数据库，全程前端碰不到任何能直接修改金币数值的参数。
• 在现有JWT逻辑基础上补全业务层校验
  • JWT解析出来的用户ID是操作的唯一目标账号，接口绝对不要接收前端传来的目标用户ID参数，防止攻击者篡改参数修改其他账号的金币。
  • 给奖励类操作加一次性凭证：用户达成通关、解锁成就这类触发奖励的条件时，服务端生成一个有效期仅几分钟的唯一凭证存在缓存里，前端必须携带这个合法凭证才能领取奖励，凭证使用后立刻作废，避免攻击者重复构造请求刷奖励。
  • 加请求防重放逻辑：所有敏感操作要求请求携带当前时间戳，服务端校验到时间戳和服务器时间差超过3分钟的直接拒绝，防止攻击者截获合法请求后重复发包刷奖励。
• 加异常风控做兜底
  • 所有金币变动留详细操作日志，记录每次变动的原因、数值、触发时间，配置基础风控规则：比如1分钟内金币涨幅远超正常游戏上限、短时间内重复触发同个高奖励操作、数值超出游戏设定的合理区间，直接触发异常告警，必要时临时冻结账号核查。
  • 所有数值变动加边界校验：比如单次操作最多发放100金币，设置用户总金币的合理上限，哪怕业务逻辑出bug，也不会出现异常巨额金币。

补充：很多刚做游戏类应用的开发者都会踩这个坑：把数值计算逻辑放在前端，后端只负责存数据，相当于把仓库钥匙直接交到所有访问者手里。你只要记死一个原则就不会出大问题：前端只负责做交互和页面展示，所有和数据、规则相关的逻辑全部在服务端闭环，从根源上堵死前端篡改的可能。

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