在 OWASP Top 10:2025 里，Mishandling of Exceptional Conditions 排在 A10，也就是第 10 位。这是 2025 新增的类别，它聚焦的是“异常条件处理不当”：系统在遇到缺参、空指针、权限不足、网络中断、资源耗尽、状态异常、事务中断、未预期输入时，没有正确地预防、识别和处理这些异常，最终进入不可预测状态，甚至直接 fail-open（失败时放行）。
来源：OWASP Top 10:2025 Introduction
来源：A10:2025 Mishandling of Exceptional Conditions

你可以把它理解成：
正常流程往往大家都会写，但真正拉开安全差距的，是系统出错时会怎样。很多应用一到异常流就开始“能跑就行”，而攻击者最喜欢钻的就是这些状态。

OWASP 为什么把它单独拉出来
官方说明，这类问题以前常被归到“代码质量差”之类过宽的桶里，但那样不利于给出安全指导。2025 版把它独立成类，是为了强调：异常处理不是工程洁癖问题，而是直接影响机密性、完整性、可用性的安全控制。

常见表现

• 输入校验缺失或不完整，异常数据一路流到深层函数才爆炸。
• 只在很高层统一 try/catch，底层出错点没有就地处理。
• 捕获到错误但什么也不做，或者吞掉异常继续执行。
• 事务执行到一半失败，却没有完整回滚。
• 权限检查失败、状态异常、网络中断时默认继续走成功路径。
• 出现异常后资源没有释放，逐步被耗尽形成 DoS。
• 同一个系统里有多套错误处理风格，行为不一致。
• 没有对重复错误、异常峰值、异常模式做监控和告警。

OWASP 官方典型场景

• 文件上传时发生异常，但程序没有释放资源，攻击者不断触发异常，最终把资源耗尽，形成拒绝服务。
• 数据库报错被原样返回给用户，泄露内部实现细节，攻击者再利用这些信息构造更精准的 SQL 注入。
• 金融交易是“扣款 -> 入账 -> 记账”三步，如果中间网络中断而系统又没有完整回滚，就可能出现资金状态损坏，甚至被攻击者利用成重复转账或资金抽走。

怎么防

• 在异常发生的地方就捕获并处理，不要把一切都丢给最上层。
• 异常处理必须做“有意义的动作”：回滚、释放资源、拒绝请求、记录日志、必要时告警。
• 建立全局异常处理器作为兜底，但它不能替代局部正确处理。
• 对事务类操作坚持 fail closed，一旦异常就整体回滚，不要“半路修补”。
• 在系统里加入限流、配额、节流、资源上限，尽量预防异常条件本身。
• 对重复错误和异常模式做监控，识别脚本化探测和攻击。
• 统一项目里的异常处理方式，不要每个模块各玩各的。
• 设计阶段就把异常流纳入威胁建模，测试阶段加入压力测试、异常流测试和渗透测试。

一句话总结
Mishandling of Exceptional Conditions 的本质是：系统在异常状态下没有安全地失败、回滚、记录和恢复，结果把“错误”变成了“漏洞”。