差点被薅哭！测试环境也能大翻车

大概就是，有人发现并利用了测试环境漏洞，通过支付沙盒和测试卡获得测试额度，再用这些额度调用实际会产生费用的 API。测试卡没有真实付款，后面的 API 调用却会消耗真实成本。

这次能及时发现问题，多亏之前给充值流程加了通知。短时间内连续出现多笔大额测试充值，明显不符合正常测试行为。

我们立马开始排查，关闭相关入口并停用异常账号和凭证，幸好没有造成大的损失。

这次复盘也提醒了我们，测试环境一定要注意安全问题。

按后果分级

很多团队会默认 dev、staging 的风险低于生产，因为里面使用测试账号、测试支付和测试数据。

但只要它还连接着付费 API、短信、邮件、云存储或其他按量计费的服务，这个环境就可能产生真实成本。攻击者不需要碰到生产数据库，只要找到一条可以重复消耗资源的路径，就足以带来损失。

以后评估测试环境，想一下这个操作在测试侧不花钱，下游会不会花真钱？

如果答案是会，它就需要接近生产环境的成本控制。

防线要分开布置

公开入口只是第一层。测试环境可以默认关闭注册，只保留预创建的团队账号，再通过访问控制限制可见范围。随机域名只能降低被顺手发现的概率，不能承担安全边界的作用。

支付和额度也要隔离。测试支付适合验证订单、回调和状态流转，不应该直接兑换成能够调用真实付费服务的余额。最好在应用层提供独立开关，让测试环境默认关闭充值能力，而不是只依赖代理层临时拦截。

外部服务的密钥要按环境拆开。测试环境使用独立密钥、较低额度和每日预算，达到阈值后自动停止调用。这样即使前面的限制失效，成本也有明确上限。

账号被禁用时，关联的 API Token、登录会话和自动化能力也要一起失效。只关闭账号入口，遗留凭证仍然可能继续工作。

访问、支付、密钥、预算和告警组成测试环境的多层防线

告警要看业务动作

这次最早出现的异常信号，就是充值通知。系统没有报错，每一笔支付请求也都显示成功，但充值金额和频率明显超出了正常测试范围。

这类问题很难只靠服务器 CPU、错误率和 500 日志发现。更有效的信号来自业务链路。短时间注册增加、连续创建 Token、测试充值突然变大、付费任务集中爆发，单独看都不一定有问题，连在一起就很值得警惕。

测试和生产的通知也要有醒目的环境标识。

复盘很重要

事故处理完成后，只修复当时被利用的入口还不够。更有价值的工作，是把教训写进系统默认值：密钥按环境隔离、预算有上限、异常自动告警等等。

同时保留必要的订单、请求、任务和审计记录。先确认影响范围，再清理账号和凭证，避免在证据还没整理清楚时删掉关键线索。