限速与滥用防护查什么
短信、验证码、登录、查询类接口如果没有限速，会被用来刷短信、撞库、遍历数据，既是业务成本问题也是账号安全问题。核查不是「有没有拦截」，而是四个维度是否都被覆盖：来源 IP、账号、设备指纹、接口本身；以及阈值是否合理、触发后是简单拒绝还是升级验证、多久恢复。验证方式要用低频递增请求逐步逼近阈值，绝不能一上来就打满。
基本信息
| 限速维度 | 来源 IP、账号、设备指纹、接口与全局总量 |
|---|---|
| 常见策略 | 固定窗口、滑动窗口、令牌桶；触发后升级为验证码或短信 |
| 关键指标 | 首次拦截的请求序号、拦截响应特征、恢复时间 |
| 验证前提 | 选择低影响接口、限定总量、提前报备时间窗口 |
| 报警联动 | 确认客户监控是否感知，避免被当作攻击处置 |
典型使用场景
- 登录与找回密码流程的撞库防护评估
- 短信与邮件接口的成本滥用风险评估
- 查询类接口的数据遍历风险评估
- 验证码接口的绕过与重复使用核查
- 修复验证：确认多维度限速已生效且恢复时间符合预期
验证步骤
验证步骤
# 用低频递增请求逼近阈值，控制总请求量在百次以内
for i in $(seq 1 30); do
curl -s -o /dev/null -w "$i %{http_code} %{time_total}\n" \
-X POST https://example.com/login -d 'user=test&pass=x';
sleep 0.5 # 显式间隔，避免瞬时打满
done
# 记录：首次被拦的序号、响应特征（状态码/验证码/提示语）、恢复所需时间
# 再换 IP 与换账号分别验证维度覆盖，观察是否只按 IP 限速响应特征与判断
| 响应特征 | 含义 | 处置 |
|---|---|---|
| 持续返回 200 且无任何限制 | 该维度无限速 | 列缺陷，按风险等级评估滥用成本 |
| 返回 429 或特定错误码 | 限速生效 | 记录阈值区间与恢复时间 |
| 强制要求验证码 | 升级验证策略生效 | 评估验证码是否可被自动化绕过 |
| 提示语随次数变化但状态码不变 | 仅前端提示 | 验证服务端是否真正拦截 |
限速验证必须控制总量：打满阈值可能触发全站封禁或风控锁定，波及真实用户，也会把测试窗口提前耗尽。
只测单一维度会得出错误结论：很多系统只按 IP 限速，换 IP 即可绕过，而账号维度才是真正影响撞库成本的一层。