「付款时没有收到 OTP」成为今次 Apple 预购事件最受关注的其中一个问题。
对 IT Team 而言，真正值得追问的，不是每一宗交易是否都要加验证，而是：
---
--- 当系统没有要求 OTP 时，还有什么控制在判断这宗交易是否可信？
--- 当企业为了流畅度降低某项安全控制时，哪一项控制会接手？
Apple 事件反映什么？
近日 iPhone 18 开放预购后，香港警方表示，截至 9 月 14 日下午 5 时，已接获 1,209 人报案，指信用卡出现与购买 iPhone 有关的怀疑未经授权交易，涉及约 2,500 万元。警方表示，涉案网上预购交易无需经一次性短信验证码（OTP）或其他认证方式，付款过程毋须经持卡人确认即可完成。这表示，若骗徒已掌握外泄的信用卡资料，便可能直接尝试完成交易。
金管局亦指出，个别商户可能基于营运考虑，不使用或暂停 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 日发布。
