防止验证码接口被刷

验证码下发一旦被脚本连打，会出现用户手机被大量无关验证码打扰、账户余额被快速消耗、通道信誉下降等问题。EngageLab OTP 可以限制发送侧的频率和用量，但拦不住你业务上那个未鉴权的「获取验证码」接口。

本文说明如何把平台能力与业务侧防护配合使用，降低接口被刷的风险。

正确架构

EngageLab OTP API 只能由你的服务端调用，不能由浏览器、App 客户端或小程序直接请求。

              
              用户 → 你的前端（登录 / 注册 / 重置密码页）
     → 你的后端（校验会话、人机验证、业务频控）
     → EngageLab OTP API（携带 API Key，并传入 end_user_ip）

            

• dev_key 与 dev_secret 只存放在服务端，不要写入前端代码、App 安装包或公开仓库。
• 前端只调用你自己的「获取验证码」接口，不要直连 https://otp.api.engagelab.cc。
• 建议为生产环境 API Key 配置调用方 IP 白名单，详见 API Key。

两种 IP 不要混用

在 安全中心 启用「按 IP 地址」频控后，必须在 验证码下发 请求中传入 end_user_ip，该限制才会生效。这里应传用户设备的公网 IP，而不是你服务器的 IP。

平台侧防护

在 OTP 控制台完成以下配置，用于限制发送侧被刷后的损失：

发送量预警或限额触发后如需收到通知，请先在 Webhook 中配置相应回调事件。

业务侧防护

平台频控无法替代你自己的「获取验证码」接口防护。建议在调用 EngageLab 之前完成这些校验：

• 发码前做人机验证（如图形验证码或 Turnstile / reCAPTCHA），并在服务端校验结果。
• 同一手机号设置重发间隔（例如 60 秒），前端同步展示倒计时。
• 按账号、设备、IP 分别限制分钟、小时、自然日的请求上限，失败请求也计入次数。
• 「获取验证码」必须带有登录态，或未登录场景下的有效会话，禁止无上下文的公开发码入口。
• 限制同一验证码的尝试次数；校验成功后立即失效。EngageLab OTP 对已验证成功的验证码不支持再次校验。

把错误码当作被刷信号

验证码下发 在发送前校验阶段可能返回以下错误。出现这些错误时，应减缓重试，并检查是否遭到集中请求：

收到 HTTP 429 时，请勿立即连续重试。如持续出现，请先在安全中心查看是否已触发送量限额或紧急止损，再联系技术支持。

密钥泄露时怎么做

1. 在 OTP 控制台 禁用或轮换 API Key。
2. 在 安全中心 使用紧急止损，暂停 SMS 发送。
3. 在 历史记录 和回调中核对异常发送。
4. 收紧 API Key IP 白名单，并检查日 / 月发送量限额是否合理。
5. 确认风险消除后再恢复发送。

上线检查清单

• API 只在服务端调用，dev_secret 未进入前端、App 或公开仓库。
• 生产环境 API Key 已配置服务器出口 IP 白名单。
• 安全中心已开启号码频控；需要按 IP 限制时，发送请求已传入 end_user_ip。
• 已设置日 / 月发送量限额，并配置了用量相关回调。
• 「获取验证码」接口在调用 EngageLab 前已做人机验证和业务频控。
• 已明确被刷时的处置顺序：禁用 Key → 紧急止损 → 核查发送记录。