Zui近我跟老朋友聊到一个超头痛的问题——短信验证码被盗刷了怎么办？

1、马上把手机号码挂起，或者换个号码。

2、立刻把所有和该手机号绑定的账号一一改密码。

3、联系运营商，说明情况，让他们帮你把SIM卡停机。

我跟你说这一步Zuo不着急，等你把门锁好之后再去想怎么防。哈哈。

大多数时候是因为接口太“裸”——没有任何限流，没有人机验证。只要脚本跑上去，就Neng不停请求。

还有就是有些开发者把短信接口暴露给前端，导致攻击者直接拿到URL再写脚本。

不对不对，还可Neng是你自己的设备指纹没加进去，让攻击者Ke以随便切换IP或浏览器。

①无秒级冷却；②同一天没有次数上限；③缺少IP/设备层面的分布式限流；④没有验证码一次性使用机制；⑤没监控报警。

第一步：在后端加一个全局锁定标记。每次请求dou先检查有没有“locked”键，Ru果有就直接拒绝。

if) throw new ForbiddenException;

第二步：把短信发送接口改成“ticket制”。前端先Zuo一次人机校验，得到ticket后才Neng调用后端。

String ticket = request.getParam;
if) throw new ForbiddenException;
redis.del; // 防止重放
// 继续发送逻辑…

因为攻击者只需要跑个小脚本，再多点人机验证就得停下来。省下来的费用可不是小数目啊！

A、**秒级冷却**：同一个手机号1分钟内只Neng请求一次。代码hen短，只要一行：

String cdKey = "sms_cd:"+phone;
if) throw new TooManyRequestsException;
redis.setex; // 60秒冷却

B、**当天上限**：24小时Zui多10次。Ru果超过就提示“今日Yi用完”。这对正常用户来说几乎不会碰到，但对攻击者就算爆破也没意义。

嘿，你可Neng会问：“那我刚发完还没收到短信怎么办？”这时候Ke以加一个重发阈值，比如30秒后才允许 请求，或者让用户确认是否收到了码再重新发送。

生成六位码后存进Redis，用TTL保留5分钟，然后删除：

redis.setex; // 5分钟有效
// 验证时：
String real = redis.get;
if) throw new ForbiddenException;
redis.del; // 一次性使用

* 用Redis统计 IP 的访问次数。比如一分钟内超过20次就触发报警或临时禁用IP。

Long cnt = redis.incrBy;
if redis.expireAt;
if alert; // 发邮件或飞书消息

* 同理，对手机号也Zuo统计。每天超过30次就直接封号并推送邮件给运营团队。

"某IP在一分钟内发起了35次验证码请求，请检查是否存在脚本攻击"

一句话：防御是多维度的组合，而不是单靠一点儿技术手段。让攻击成本变高，同时尽量保持用户体验的连贯性，这才是真正的安全运营套路。懂吗？Ru果还有疑问，随时来聊聊，我这边也Ke以帮你写一套示例代码，保证你从此不再担心验证码被盗刷！💪🎉