如何防止Node.js REST API被伪造Payload调用？游戏高分安全问题

当前实现的核心问题 #

• 完全信任客户端上报的分数：这是最致命的漏洞——前端属于完全不可信环境，恶意用户可通过修改请求体、模拟API调用等方式随意篡改分数，后端无任何校验就直接存储，等于把奖品发放的控制权交给了攻击者。
• JWT存储方式存在风险：localStorage易遭XSS攻击窃取令牌，一旦泄露，攻击者不仅能伪造分数，还能以用户身份执行其他操作。
• 缺乏分数合理性校验逻辑：后端未对分数的真实性、合理性做判断，比如分数是否超出游戏理论最大值、完成时间是否符合常理等，导致异常分数无法被拦截。
• 无操作追溯机制：未记录分数提交的上下文信息，出现作弊后无法回溯验证，难以定位恶意行为。

针对性解决方案 #

1. 后端主导分数计算，彻底杜绝前端篡改 #

禁止前端直接上报最终分数，改为上报游戏过程中的原始操作数据（比如每一步的点击动作、关卡进度、时间戳、随机挑战因子等），由后端根据这些数据重新计算真实分数：

• 游戏开始前，后端生成唯一challengeId和随机因子返回给前端；
• 前端在游戏过程中记录每一步操作的时间、动作类型，并携带challengeId；
• 提交时，前端将所有操作数据和challengeId发给后端，后端先验证challengeId有效性，再根据操作数据计算真实分数后存储。
  这种方式下，前端就算篡改操作数据，后端也能通过逻辑校验（比如操作时间顺序不合理、动作不符合游戏规则）发现异常，无法直接伪造高分。

2. 优化JWT存储与安全 #

• 将JWT从localStorage迁移至HttpOnly、Secure、SameSite=Strict的Cookie中，浏览器会禁止前端JS访问Cookie，有效防范XSS攻击窃取令牌；
• 缩短JWT有效期（比如15分钟），配合刷新令牌机制，用户在令牌过期前可通过刷新令牌获取新的访问令牌，兼顾安全性与用户体验。

3. 增加分数合理性校验 #

• 设置分数上限阈值：根据游戏规则定义单局理论最高分，超过该分数的请求直接拒绝；
• 校验游戏时长：记录游戏开始与结束的时间戳，若时长过短（比如某游戏最少需3分钟完成，提交时长却仅10秒），直接判定为作弊；
• 建立用户分数画像：记录用户历史分数的平均值、波动范围，若某次分数远超历史水平，触发人工审核或临时冻结该分数，核查后再决定是否发放奖品。

4. 完善操作审计与追溯 #

• 后端记录每一次分数提交的详细日志：包括提交时间、用户IP、用户代理、challengeId、操作数据摘要等，发现作弊行为时可通过日志回溯验证；
• 高价值奖品对应的分数强制开启人工审核环节，尤其是异常分数，避免自动发放造成损失。

5. 前端反作弊（仅作辅助，不能依赖） #

前端反作弊仅能作为补充，因为极易被绕过：

• 检测页面是否处于调试模式（比如检查window.devtools.open状态），但攻击者可通过修改浏览器配置绕过；
• 对游戏关键数据进行简单签名（注意签名密钥绝对不能放在前端代码中，否则会被破解），后端验证签名有效性，防止数据被篡改。

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