在 OWASP Top 10:2025 里，Insecure Design 排在 A06，也就是第 6 位。它从 2021 年的第 4 位降到了第 6 位，但这并不代表它不关键。相反，OWASP 把它保留在榜单里，就是因为很多严重安全问题并不是“代码写错了”，而是从需求、流程、权限模型、业务状态机、租户隔离到失败状态设计，一开始就没有把安全控制设计进去。
来源：OWASP Top 10:2025 Introduction
来源：A06:2025 Insecure Design

你可以把它和“实现缺陷”分开理解：

• Insecure Implementation：本来设计是对的，但写代码时写坏了。
• Insecure Design：设计阶段就没把控制做出来，后面代码写得再认真，也只是把一个不安全的方案实现得更稳定。

OWASP 官方强调的重点
这个类别的核心表述是 “missing or ineffective control design”，也就是“控制缺失”或“控制设计无效”。OWASP 还特别强调三件事：

• 需求与资源管理要把安全要求谈清楚
• 设计阶段要做威胁建模
• 开发过程要有安全开发生命周期，而不是等上线前才补洞

常见表现

• 找回密码依赖“安全问题答案”这类天然不可靠的方案。
• 认证、授权、关键业务流没有做威胁建模。
• 业务状态机允许跳步、重复消费、并发绕过、异常回退不一致。
• 多租户隔离只靠表字段，没有架构或边界层面的强隔离。
• 关键业务没有考虑失败流、误用流和攻击流。
• 缺乏反机器人、反批量滥用、反羊毛的业务规则。
• 安全需求没有进入用户故事、验收标准和设计文档。

OWASP 官方典型场景

• 用“密保问题”做找回密码，实际上谁都可能知道这些答案，根本不能作为身份证明。
• 影院预订系统有团体折扣和押金规则，但没有防滥用设计，攻击者可以用极少请求锁掉大量座位，直接造成业务损失。
• 电商系统没有针对抢购机器人做业务规则设计，黄牛脚本可以瞬间扫空高价值商品，引发品牌和用户层面的连锁损害。

怎么防

• 在需求阶段就定义机密性、完整性、可用性、真实性等保护要求。
• 把安全活动前移到编码之前，尤其是认证、授权、关键业务流和数据流的设计阶段。
• 建立并复用安全设计模式或“铺装路”组件，而不是每个团队自己发明。
• 对关键流程做威胁建模，重点关注访问控制、业务逻辑、失败状态和异常状态。
• 在用户故事里写清楚正常流、失败流、误用流。
• 对前后端每一层都做合理性检查，不让错误状态一直向下传播。
• 为关键流编写单元测试和集成测试，不只验证“能跑通”，还要验证“能抗滥用”。
• 对高暴露系统和多租户系统做更强的分层与隔离设计。

一句话总结
Insecure Design 的本质是：系统不是后来才被写坏的，而是一开始就没有把正确的安全控制设计进去。