防止驗證碼介面被刷

驗證碼下發一旦被腳本連打，會出現使用者手機被大量無關驗證碼打擾、帳戶餘額被快速消耗、通道信譽下降等問題。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 → 緊急止損 → 核查發送紀錄。