光靠校验手机号格式、不加前置防护的sendSmsCode接口极易被滥刷，2026年真实案例单小时盗刷超12万条、损失超80万元；单纯Redis按IP限流因代理池、拨号换IP等手段而失效，且误伤NAT共享IP的正常用户；必须采用“设备指纹+时效签名+行为熔断”三段式防御，并在反向代理后、业务路由前执行。
直接说结论：光靠校验手机号格式、不加任何前置防护的 sendSmsCode 接口，等于把短信通道钥匙挂在门口。2026年真实案例里，单次盗刷峰值超 12 万条/小时，成本直接冲破 80 万元——这不是理论风险，是已经反复发生的生产事故。
为什么单纯用 Redis 按 IP 限流在短信接口上效果差？
因为攻击者早就不靠固定 IP 刷了。他们用代理池、家庭宽带拨号换 IP、甚至手机热点轮发，redis.incr("limit:{ip}") 在这种场景下基本形同虚设。更麻烦的是：正常用户用 WiFi + 4G 切换、公司 NAT 出口共用一个公网 IP，一限就误伤一片。
- 同一办公区几十人共用一个出口 IP，
MAX_SENDS_PER_MINUTE=3会导致注册流程集体卡死 - 攻击者用 500 个住宅 IP 轮询，每个 IP 每分钟只发 1 次，总量照样轻松破千
- Redis key 过期时间写死 60 秒，但滑动窗口实际需要按请求时间戳动态计算，否则存在时间切片漏洞
必须组合使用「设备指纹 + 时间戳签名 + 行为阈值」
只做一层防护，等于没做。2026 年主流防御链是三段式落地：
-
前端生成轻量设备指纹：不是要识别精确机型，而是用
navigator.userAgent + screen.width + screen.height + navigator.language + Date.now()拼接哈希（服务端不校验全字段，只比对哈希前 8 位），存入请求 header 的X-Device-Fp -
请求带时效签名：所有
/api/sendSmsCode请求必须含timestamp（秒级 Unix 时间戳，误差 > 300 秒直接拒）和signature（用hmac-sha256对phone+timestamp+nonce签名，密钥不暴露在前端） -
后端行为熔断：对同一个
phone，10 分钟内第 3 次请求就触发图形验证码；对同一X-Device-Fp，5 分钟内超过 5 次请求就进滑动验证队列
验证码不是“加了就行”，关键看触发时机和降级策略
很多团队把图形验证码放在第一次请求就弹，结果正常用户还没点第二下就卡住——这叫安全压垮体验。真正有效的做法是“渐进式挑战”：
立即学习“Python免费学习笔记（深入）”；
- 首次请求：只校验签名和 timestamp，通过即发码（快）
- 同一手机号 2 分钟内第 2 次请求：返回
{"need_captcha": true, "captcha_id": "xxx"}，前端才加载验证码组件 - 若连续 2 次验证码失败，后续 1 小时内该手机号所有请求直接返回 429，不给重试机会
- 注意：验证码图片的
captcha_id必须绑定到 Redis 的captcha:{id}，且设置 5 分钟 TTL，过期即失效，不能靠前端控制
最常被忽略的一点：所有防刷逻辑必须在反向代理（如 Nginx）之后、业务路由之前执行。如果把限流写在 Flask 的 @app.route 里，攻击流量已经打穿了 Web 服务器连接池——这时候再拦，黄花菜都凉了。
