Apple 盜刷事件談 OTP：流暢度與安全，真的只能二選一嗎？

「付款時沒有收到 OTP」成為今次 Apple 預購事件最受關注的其中一個問題。

對 IT Team 而言，真正值得追問的，不是每一宗交易是否都要加驗證，而是：

• － 當系統沒有要求 OTP 時，還有什麼控制在判斷這宗交易是否可信？
• － 當企業為了流暢度降低某項安全控制時，哪一項控制會接手？

Apple 事件反映什麼？

近日 iPhone 18 開放預購後，香港警方表示，截至 9 月 14 日下午 5 時，已接獲 1,209 人報案，指信用卡出現與購買 iPhone 有關的懷疑未經授權交易，涉及約 2,500 萬元。警方表示，涉案網上預購交易無需經一次性短訊驗證碼（OTP）或其他認證方式，付款過程毋須經持卡人確認即可完成。這表示，若騙徒已掌握外洩的信用卡資料，便可能直接嘗試完成交易。

資料來源：香港電台新聞（2026 年 9 月 14 日）

金管局亦指出，個別商戶可能基於營運考慮，不使用或暫停 App 認證、一次性密碼等額外認證安排；在這類情況下，商戶須承擔未經授權交易的責任及相關財務損失。

資料來源：Now 新聞

我們近期亦有一個客戶案例。客戶為了提高網上報名流暢度而停用 CAPTCHA，結果出現大量 BOT 自動化請求及落單行為。問題處理後，團隊再次擔心驗證影響用戶體驗，於是重新停用 CAPTCHA，結果同類 BOT 活動再次出現。

兩個案例涉及不同控制，但反映同一個管理盲點：

企業將安全控制當成只有「啟用」或「停用」兩個選項。

先分清楚每項控制

以下為比較常見的防護處理方式。每種方式處理不同問題，不能互相取代。如果活動同時涉及登入、報名、名額及付款，便可能需要多個控制層共同運作。

CDN／DDoS 防護

• － 主要處理的問題：在網絡邊緣吸收、過濾或分流大量流量。
• － 停用或不足時的風險：突發流量可能直接到達網站及應用伺服器，造成服務不穩或中斷。

CAPTCHA

• － 主要處理的問題：要求使用者完成額外挑戰，增加 BOT 自動化操作成本。
• － 停用或不足時的風險：BOT 更容易大量註冊、登入、報名或落單，搶先佔用名額及庫存，亦增加後端處理負荷。

行為式 BOT 偵測

• － 主要處理的問題：根據請求模式、瀏覽路徑、裝置及操作行為識別可疑活動。
• － 停用或不足時的風險：較慢速或模仿真人的 BOT 可能持續通過，令自動化濫用集中於報名、庫存、優惠碼或付款等高價值流程。

Rate Limiting

• － 主要處理的問題：限制單一 IP、帳戶或裝置的請求頻率。
• － 停用或不足時的風險：大量或重複請求可在短時間內湧入，消耗應用程式、API、資料庫及第三方服務資源，增加延遲、錯誤及服務被濫用的風險。

排隊機制（Queueing Mechanism）／虛擬等候室（Virtual Waiting Room）

• － 主要處理的問題：控制大量真人同時進入系統。
• － 停用或不足時的風險：大量用戶同時觸發登入、查詢或寫入，可能令應用程式及資料庫超出負荷，造成延遲、錯誤、交易失敗或服務中斷。

OTP／3-D Secure／App 認證

• － 主要處理的問題：驗證付款或高風險帳戶操作。
• － 停用或不足時的風險：已被盜取的信用卡、帳戶或付款資料可能在沒有持卡人即時確認下完成操作，增加未經授權交易、退款及財務責任風險。

高流量活動要先分流

從事件中學習，應付高流量時，我們不應只問「流量有幾多」，而要先判斷流量類型：

• － 大量真人在短時間內正常進入。
• － 同一批裝置或 IP 大量重複請求。
• － 請求速度及流程高度一致，明顯由程式自動操作。
• － BOT 刻意放慢速度，模仿真人，但集中攻擊報名、名額、庫存或落單步驟。

第一種主要是容量及排隊問題；其餘情況則較接近 BOT 或流程濫用，處理方法不能只靠增加伺服器容量。

Rate Limiting 可以限制例如「每個 IP 每分鐘最多提交幾次」，但不是完整的 BOT 防護。BOT 可以分散到大量 IP、刻意放慢速度，亦可以只集中攻擊一個高價值步驟，例如搶名額、驗證優惠碼或提交訂單。

因此，Rate Limiting 應與帳戶、裝置、工作階段及行為訊號一同使用，而不是停用 CAPTCHA 後唯一的替代方案。

如果大量真人同時進入，則可以考慮：

• － 虛擬等候室（Virtual Waiting Room），配合排隊及分批放行機制。
• － 分批放行及設定每批人數。
• － 對庫存、名額或提交按鈕實施伺服器端鎖定。
• － 將非必要功能延後處理，避免所有請求同時觸發資料庫寫入。
• － 為活動設定獨立監察指標，例如請求率、錯誤率、登入失敗率及每分鐘成功提交數。

名額、庫存、折扣碼及付款條件，不能只靠前端隱藏按鈕或顯示 CAPTCHA；前端控制只能改善介面流程，不能作為真正的存取控制，伺服器端仍必須重新驗證。

將挑戰集中在高風險用戶

較好的做法不是對所有人顯示 CAPTCHA，而是在背景評估風險。可以留意：

• － 新裝置或新帳戶。
• － 短時間內重複建立帳戶或提交表格。
• － 同一裝置快速切換多個帳戶。
• － 大量請求集中於名額、庫存或付款步驟。
• － IP、裝置及帳戶的地理位置或使用模式出現異常組合。
• － 付款資料、收貨資料或交易行為突然偏離過往模式。

低風險用戶可以保持正常流程；風險較高的用戶才需要 CAPTCHA、OTP、3-D Secure、App 認證、延遲處理或人手覆核。

這不代表每項安全控制都要對所有用戶啟用，而是要讓系統在風險上升時自動增加防禦，避免團隊只能在「全部啟用」和「全部停用」之間選擇。

停用控制前的 5 條問題

下一次有人提出「先停用 CAPTCHA」或「先不要觸發 OTP」時，IT Team 可以先確認：

1. 今次要處理的是哪種風險？

是 BOT、DDoS、流量過高、帳戶濫用，還是未經授權交易？不同風險不能由同一項控制處理。

2. 停用後由哪個控制接手？

是行為式 BOT 偵測、裝置風險評分、排隊機制，還是其他交易風險分析？如果沒有替代措施，便不應只因流暢度而停用原有控制。

3. 哪些行為會觸發額外挑戰？

例如短時間重複提交、同一裝置切換多個帳戶、集中攻擊特定流程，或付款模式突然出現異常。

4. 如何確認控制真的有效？

是否有 BOT 命中率、誤判率、請求來源、成功落單率、OTP 觸發率、OTP 豁免率、驗證失敗率及異常錯誤率等數據？

5. 誰可以批准變更，以及何時恢復？

停用是否有明確期限？活動結束、流量下降或異常率上升時，會否自動重新啟用？是否需要 IT、業務、風險或系統負責人共同批准？

如果以上問題沒有答案，團隊不是在優化用戶體驗，而是在接受一項未經評估的風險。

成熟的設計，不是單純增加更多驗證，而是讓低風險用戶少受阻礙，讓高風險行為被延遲、驗證或攔截，同時保留足夠的監察及回復能力。

下一次高流量活動之前

下一次高流量活動開始前，IT Team 不妨先問：

如果我們關掉這項控制，哪一項控制會接手？

如未能即時回答，可以先進行一次 Security Health Check 或活動前 technical review，針對 BOT 防護、流量控制、OTP／3-D Secure 觸發邏輯、監察指標及變更回復安排，確認系統是否真的能夠同時承受高流量及高風險行為。

CAPTCHA 處理 BOT，OTP 處理高風險交易，Rate Limiting 控制請求速度，虛擬等候室控制真人高峰；如果其中一項控制被調低，IT Team 必須知道哪一項控制會接手。

安全與流暢度從來不是二選一，而是一道需要有人陪你逐層拆解的設計題。懂AI，更懂你 UD相伴，AI不冷。

如果你暫時答不出「關掉這項控制之後，哪一項控制會接手」，那正是值得做一次檢視的時候。UD 同行 28 年，我們手把手教你完成每一步，由 BOT 防護、流量控制、OTP／3-D Secure 觸發邏輯，到監察指標與變更回復安排，逐項確認你的系統是否真的承受得住下一次高峰。

由 UD 網絡安全團隊（香港）覆核。2026 年 9 月 15 日發佈。