防刷接口参数校验：压缩备份场景下的实用技巧

做后台接口开发时，谁没遇到过被脚本狂刷的糟心事？尤其是提供文件压缩、备份下载这类服务的接口，一旦暴露在外网，分分钟就被爬虫盯上。用户还没怎么用，服务器资源先被耗光了。

为什么压缩备份接口容易被刷

这类接口通常接收几个简单参数，比如文件ID、压缩格式（zip/tar.gz）、是否包含子目录等。请求逻辑清晰，返回结果固定，正好成了自动化脚本的“理想目标”。有人写个循环，批量请求不同ID的压缩包生成，不仅占用CPU和带宽，还可能触发存储爆炸。

参数校验是第一道防线

很多人觉得加个验证码或者IP限流就够了，但其实最基础也最关键的，是把接口的参数校验做扎实。别小看这一步，很多攻击都是从畸形参数开始试探的。

举个例子，你允许用户传一个 file_ids 数组来批量压缩文件，但如果不对这个数组长度做限制，别人一口气传5000个ID过来，系统直接卡死。正确的做法是在解析参数时就设置上限：

if (!Array.isArray(fileIds) || fileIds.length > 20) {
  throw new Error('文件数量超出允许范围');
}

// 同时检查每个ID是否为合法字符串或数字
fileIds.forEach(id => {
  if (!/^[a-zA-Z0-9]{1,32}$/.test(String(id))) {
    throw new Error('非法文件ID');
  }
});

别让参数变成注入入口

有些开发者图省事，直接把前端传来的压缩格式拼进命令行执行，像这样：exec(`zip -r ${filename}.${format} ${dirPath}`)。如果 format 参数没校验，别人传个 ; rm -rf / 过来，后果不用多说了吧？

正确姿势是白名单机制：

const allowedFormats = ['zip', 'tar.gz', 'rar'];
if (!allowedFormats.includes(format)) {
  format = 'zip'; // 默认安全值
}

时间戳+签名，防重放攻击

除了参数本身，还可以在请求里加个时间戳和签名。比如客户端请求时带上 timestamp=1712345678&sign=abc123，服务端用预设密钥对参数按字典序拼接后做HMAC签名验证。这样即使别人抓到了包，改不了参数，也复用不了请求。

实际中见过太多只做登录鉴权却忽略参数校验的案例。用户登录了就等于可信？错。账号被盗、接口泄露、CSRF攻击哪个不是从“已登录”状态发起的？

日志里藏着线索

加上校验后，别忘了记录异常请求。某天发现大量来自同一个IP的非法ID尝试，可能是扫描行为；如果同一用户频繁提交超长参数，得考虑是不是接口设计有问题，或者被人盯上了。

真正的防护不是靠一层墙，而是层层设防。参数校验看着不起眼，却是成本最低、见效最快的一环。特别是在压缩、导出、备份这类资源密集型操作中，早一分钟堵住漏洞，就能少一分风险。