如何防止REST API被恶意调用，避免音乐播放量被恶意刷取？

核心原则：所有前端侧的上报逻辑都可被篡改，校验规则必须全部下沉到后端实现，前端只能做辅助的逻辑校验。
具体可落地的防范措施如下：

• 新增播放会话token校验
  用户点击播放某首歌曲时，后端为这次播放生成唯一的play_token，token中绑定用户ID、歌曲ID、生成时间、最早可上报时间（生成时间+30秒）、过期时间（比如生成时间+10分钟），同时对token做签名防止篡改。前端调用播放量上报接口时必须携带该token，后端先校验：
  1. token签名是否合法、未过期
  2. token绑定的用户、歌曲是否和上报参数一致
  3. 当前时间是否晚于最早可上报时间
  4. 该token未被使用过（校验通过后立即标记token作废，无法二次调用）
     无有效token的上报请求直接拦截。
• 增加请求频率与行为规则校验
  后端添加多层限流规则：
  1. 同一用户对同一首歌曲，5分钟内最多允许上报1次有效播放
  2. 同一账号单日播放量上报上限设为合理阈值（比如200次，超出部分直接忽略）
  3. 同一IP短时间内上报请求量超过阈值直接触发验证码或临时拦截
  4. 若用户未请求过对应歌曲的音频资源，直接拒绝其上报请求
• 上报参数加密与前端混淆
  提高普通用户的刷取门槛：
  1. 上报请求的参数中加入当前时间戳、用户ID等字段，拼接后和后端约定的密钥做签名，后端校验签名不匹配直接拦截
  2. 对前端JS代码做混淆、压缩，隐藏加密逻辑和接口参数规则，大幅提升破解成本
• 离线数据清洗校正
  不要实时将上报数据计入正式播放量：
  1. 上报的播放数据先进入待校验队列，24小时后经过风控校验再计入正式统计值
  2. 定期离线清洗异常数据，比如同一IP批量重复上报、播放量和音频资源请求量偏差过大的异常数据，直接扣减对应的播放量

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