如何安全防护JavaScript API请求？防止刷取视频奖励的方案求助

我来给你几个能从根源上抵御刷奖励行为的方案，覆盖客户端到服务端的多层校验，帮你彻底解决这个问题：

1. 把核心校验逻辑完全移到服务端 #

客户端的任何代码都可能被篡改，所以永远不要相信客户端传来的“播放完成”信号。你可以借助YouTube的官方API在服务端做合法性验证：

• 当视频播放结束时，客户端除了发起奖励请求，还要把YouTube播放器返回的「播放会话标识」「视频ID」「当前用户ID」一起发送给服务端。
• 服务端拿着这些参数，调用YouTube Data API（需要提前申请服务端API密钥），验证这个会话是否真的完成了完整播放——比如检查播放时长是否等于视频总时长，播放状态是否为正常结束。
• 只有服务端验证通过后，才发放奖励，完全跳过客户端的“播放完成”判断。

2. 隐藏关键函数，避免全局暴露 #

你之前的requestRewardFromServer是全局可访问的，这才给了控制台调用的机会。可以把它封装在闭包里，不让它暴露到全局作用域：

(function() {
  // 私有函数，外部无法直接访问
  function requestRewardFromServer(playSessionId) {
    // 携带会话标识等参数发起请求
    const xhr = new XMLHttpRequest();
    xhr.open('POST', '/api/reward', true);
    xhr.setRequestHeader('Content-Type', 'application/json');
    xhr.send(JSON.stringify({
      userId: '当前用户ID',
      videoId: '目标视频ID',
      playSessionId: playSessionId
    }));
  }

  // 仅YouTube API回调能触发的播放完成判断
  function videoStoppedPlaying(event) {
    const player = event.target;
    // 先在客户端做基础校验：播放进度接近视频总时长（允许1秒误差）
    if (player.getDuration() - player.getCurrentTime() < 1) {
      const sessionId = player.getVideoData().video_id + '_' + Date.now(); // 生成会话标识
      requestRewardFromServer(sessionId);
    }
  }

  // 绑定YouTube播放器的状态变更事件
  const player = new YT.Player('youtube-player', {
    events: {
      'onStateChange': function(event) {
        // 仅当状态变为已结束（0）时触发
        if (event.data === 0) {
          videoStoppedPlaying(event);
        }
      }
    }
  });
})();

这样控制台里根本找不到requestRewardFromServer这个函数，自然无法手动调用。

3. 给请求加签名验证 #

即使有人能伪造请求参数，签名机制可以让服务端快速识别非法请求：

• 页面加载时，服务端给当前用户生成一个唯一的临时token（绑定用户ID和当前会话），返回给客户端。
• 客户端发起奖励请求时，把userId、videoId、token、当前时间戳用HMAC算法（比如HMAC-SHA256）生成一个签名，和参数一起发送。
• 服务端收到请求后，用相同的密钥重新计算签名，和客户端传来的签名对比——只有签名一致，才处理请求。

4. 服务端加奖励发放限制 #

从业务逻辑层面限制刷取可能：

• 同一个用户对同一个视频，24小时内只能领取一次奖励，服务端记录每个用户的领取历史，请求时先做校验。
• 检测异常行为：比如某个IP/用户在短时间内频繁请求多个视频的奖励，直接拒绝并标记为可疑账号。

5. 优化你的时间戳方案 #

你提到的时间戳方案可以进一步完善：

• 客户端在视频开始播放时记录时间戳，结束时再记录一次，把两个时间戳都发给服务端。
• 服务端计算两个时间戳的差值，对比视频的实际时长，允许3-5秒的误差（考虑网络延迟、加载时间），如果差值远小于视频时长，直接拒绝请求。

总之，客户端混淆只是“隔靴搔痒”，真正的安全核心是服务端的强校验——把所有关键判断放在服务端，客户端只负责收集数据和触发请求，这样无论攻击者怎么篡改客户端代码，都没法绕过服务端的验证。

内容的提问来源于stack exchange，提问作者Maxim van Dijk