先把名字搞清楚:OWASP 是什么
OWASP 全名是 Open Web Application Security Project,一个全球性的非营利基金会。1990 年代末由几位做 Web 应用安全的工程师在邮件列表里发起,现在有几千个志愿者维护一系列免费公开的安全资料——任何人、任何公司都能下载、引用、用在自己产品里,不用付钱。
OWASP 最出名的产出是 OWASP Top 10——每隔几年更新一次,列出 Web 应用最常见的 10 类漏洞(SQL 注入、访问控制失效、加密失败、SSRF…)。全球几乎所有的安全审计、渗透测试报告、合规检查清单,都拿这份 Top 10 做基准。
除了 Top 10,OWASP 还维护几份核心资料:
- OWASP Cheat Sheets —— 几百个具体场景的速查表(怎么存密码、怎么验证 JWT、怎么防 CSRF)
- OWASP ASVS(Application Security Verification Standard)—— 应用安全验证标准,做审计时的检查框架
- OWASP Secure Product Design Cheat Sheet —— 在设计阶段就该想到的安全原则。就是这篇要讲的 6 条出处
完整版里还有几条 Coursera 没讲(Fail Securely / Don’t Trust Services / Establish Secure Defaults / Don’t Roll Your Own Crypto),那 4 条放在文末附录。
这 6 条原则是什么
光看一遍名字:
| # | 原则 | 一句话 |
|---|---|---|
| 1 | 最小化攻击面(Minimize Attack Surface) | 关掉所有不用的入口——端口、服务、API、账号 |
| 2 | 最小权限(Least Privilege) | 只给刚好够完成任务的权限,不多一点 |
| 3 | 纵深防御(Defense in Depth) | 多层独立防线,一层失守还有下一层 |
| 4 | 职责分离(Separation of Duties) | 关键操作必须多人参与,不能一个人单独完成 |
| 5 | 保持简洁(Keep Security Simple) | 复杂的安全设计 = 没人遵守的安全设计 |
| 6 | 正确修复(Fix Security Issues Correctly) | 找根因,不要只修症状 |
记忆口诀:「减权深分简修」——减(攻击面)、权(限)、深(防)、分(职)、简、修。
怎么用这 6 条:6 个检查问题
这 6 条不是给考试背的清单——是设计新功能时要逐条问自己的 6 个问题。
任何新功能上线前,过一遍:
- 我减少了攻击者的目标吗?
- 我给的权限是不是刚好够用,没多?
- 我有几层独立防御?一层挂了下一层挡得住吗?
- 关键操作要不要多人参与?
- 我的设计够简单到能维护吗?
- 我修的 bug 是症状还是根因?
6 个问题都能回答 yes → 这是个合理的安全设计。任何 1 个 no → 那里就有漏洞。
6 条原则的内在结构
光看名字这 6 条像 6 堆杂事。按攻防时序分三组就能看出它们的关系:
| 阶段 | 在干什么 | 原则 |
|---|---|---|
| 事前 | 缩小攻击者的目标 | 1. 最小化攻击面 · 2. 最小权限 |
| 事中 | 增加攻击者的难度 | 3. 纵深防御 · 4. 职责分离 |
| 事后 | 让防御能持续运行 + 进化升级 | 5. 保持简洁 · 6. 正确修复 |
少任何一组都崩盘:没事前 → 暴露面太大防不胜防;没事中 → 单点失陷连环垮;没事后 → 防御本身成了维护负担,同样问题反复出。
接下来逐条讲——每条给出反面教材 + 实战清单 + 业务对照。
事前:缩小攻击者的目标
1. Minimize Attack Surface(最小化攻击面)
关掉所有不用的功能、端口、服务、API、账号——攻击者能利用的入口越少越好。
你不开的门窗,小偷就不能从那里进。每多开一个端口/服务/账号——攻击面就大一点,就多一个潜在入口。
| 反面教材 | 正确做法 |
|---|---|
| 服务器开了 50 个端口”以防万一”(SSH/HTTP/FTP/Telnet/MySQL/Redis…) | 默认 deny,只开必要端口(SSH/HTTPS) |
| 注册了一个 admin 接口准备给将来用,URL 已经能访问 | 没用的功能直接删,不留在代码里 |
| 离职员工账号 1 年了还在 | 24 小时内禁用、季度清理 |
关键区分:Attack Surface vs Attack Vector —— Surface 是所有潜在入口的总和(状态,一直存在,缩小它),Vector 是攻击者实际走的路径(动作,攻击时才有,拦截它)。比喻: Surface 是你家所有门窗,Vector 是小偷翻进来走的那条路。本原则专门处理 Surface。
2. Principle of Least Privilege(最小权限原则)
每个用户/服务/应用只给”刚好够完成任务”的最低权限——多一点都不给。
最小权限不止”权限要小”,还有三个含义: 够小(够用就好)+ 有期限(任务完成就撤回)+ 定期审计(看谁有权限不该有)。
| 反面教材 | 正确做法 |
|---|---|
| 所有员工都是 admin “为了方便” | RBAC 分级:Owner / Admin / Manager / Staff / ReadOnly |
| API key 是 Global(能改 DNS / R2 / Workers 一切) | 为每个用途创建独立的最小权限 token,加 IP 白名单和过期时间 |
| 数据库连接用 root 账号 | 应用账号只能 SELECT/INSERT/UPDATE/DELETE 自己的库,不给 DROP/ALTER |
| 所有服务都用 root 运行 | 每个服务用专属低权限账号 |
事中:增加攻击者的难度
3. Defense in Depth(纵深防御)
多层防御,一层失守还有下一层——不依赖任何单一防线。
纵深防御的关键不是”加更多东西”,而是每一层独立工作。如果你的 5 层防御都依赖同一个密钥/同一个账号——实际上只有 1 层。
| 反面教材 | 正确做法 |
|---|---|
| ”我有 Cloudflare WAF 就够了” | 5 层独立: WAF → 防火墙 → 反向代理 → 应用认证 → 行级数据访问控制 |
| 所有保护都依赖”登录” | 即使登录被绕过,数据层、网络层还能挡 |
| ”数据加密了就安全”,但密钥放在同一台服务器 | 数据加密 + 密钥分离存储(KMS / HSM) |
实战中常见的 5 层数据保护: 网络隔离 → 应用认证 → 授权(RLS)→ 字段级加密 → 审计日志。每一层失守,下一层还能挡——这才是真正的纵深防御。
4. Separation of Duties(职责分离)
关键操作必须多人参与才能完成——一个人单独完成不了重要决策。
职责分离既防单点恶意,也防单点失误。一个人不能同时录支出申请和批准支出。
| 操作 | 单人 | 双人 |
|---|---|---|
| 转账 / 支付 | ❌ | ✅ |
| 删除生产数据 | ❌ | ✅ |
| 发布新版本到生产 | ❌ | ✅ |
| 修改安全配置 | ❌ | ✅ |
| 查看客户敏感信息 | ⚠️ | ✅ |
个人公司怎么办? 没法做真正的双人职责分离,但有 5 种伪职责分离的替代: 时间分离(重要操作 24h 延迟)、工具强制(网页+CLI 双重确认)、双重 MFA、脚本审计 + 自动告警、用 AI 做”另一双眼睛” review 代码和配置。处理客户 PII 的业务长大后必须招第二个人——不是忙不过来才招,是结构性合规要求。
事后:让防御能持续 + 进化
5. Keep Security Simple(保持简洁)
复杂的安全设计 = 没人遵守的安全设计 = 没安全。
在你能承受的复杂度内做最强的安全。超过这个复杂度的方案——比方案不存在更糟。
经典反面教材:密码策略地狱——要求 18 位、大小写+数字+3 种符号、不能含名字、每 30 天换一次、不能和过去 24 个密码相似。结果所有员工把密码写在便利贴贴显示器旁。安全水平比”无规则”还差。
判断一个安全控制是否过度设计的三道测试:
- **30 秒能用大白话讲清楚吗?**讲不清就太复杂
- **员工有没有想”怎么绕过这个限制”?**有就太复杂
- **维护成本 > 它防的损失期望?**是就过度工程
关键认知:安全成本应匹配业务阶段。Solo + 无客户敏感数据 → MFA + WAF + 自动备份就够;接 10+ 个企业客户才需要 SIEM + 渗透测试 + 24/7 监控。提前上太重的安全 = 团队疲惫 + 系统失效。
6. Fix Security Issues Correctly(正确修复)
找根因 → 修根因 → 测试修复有效 → 监控防再发生。
不要”修一个算一个”,要找为什么会出这个问题,把根因修掉——否则同样问题会反复出现。
最常见的错误修复(只修症状,根因还在):
| 症状 | 错误修复 | 为什么错 |
|---|---|---|
| 员工密码被破解 | 让员工换密码 | 没修”为什么密码弱” |
| SQL 注入被发现 | 这一处加 escape | 其他地方还有 |
| 服务器被入侵 | 重装系统 | 没找入侵途径 |
| 配置错误导致泄漏 | 改回正确配置 | 没改”为什么会改错” |
用 5 Why 找根因:任何事故连问 5 次”为什么”,问到结构性原因为止。比如客户 A 看到客户 B 的数据——表面是”权限设错了”,连问 5 次会查到”公司没有新员工权限分级策略”——这才是根因。
修复优先级:技术 > 流程 > 培训。很多人遇到事故第一反应是”加强培训”,这经常是错误修复——培训对抗人性(3 个月就忘)、不防恶意行为、不解决系统问题。正确顺序: 先用技术控制(环境隔离、权限工作流、异常告警),再补流程(SOP、审批),最后才是培训。
反例对比:
- ❌ “加强培训让员工不点钓鱼链接”(依赖人)
- ✅ “邮件网关装反钓鱼工具自动拦截”(依赖系统)
不只是 6 条:OWASP 官方还强调的 4 条
Coursera 整理的 6 条是教学简化版。OWASP 官方文档(Secure Product Design Cheat Sheet)还强调 4 条值得记住:
- Fail Securely(安全失败)——系统挂了默认拒绝,不能默认放行
- Don’t Trust Services(不信任外部服务)——所有外部输入永远验证再用
- Establish Secure Defaults(默认安全配置)——新用户/新功能默认最严格,主动放宽
- Don’t Roll Your Own Crypto(不要自己写加密)——用 bcrypt / argon2 / AES-256-GCM / TLS 1.3 等成熟库,99% 自己写的加密有漏洞
把 6 原则当决策框架的实战用法
设计新功能时
功能需求: 让客户上传护照扫描件 → 用 6 原则审一遍——
- 最小化攻击面:能不让客户上传吗?必须上传的话能限文件类型/大小吗?
- 最小权限:上传后谁能看?只有处理这个客户的员工
- 纵深防御:扫描件存哪?加密 + 限期销毁 + 审计访问
- 职责分离:删除要不要审批?谁能授权销毁?
- 保持简洁:客户操作流程要简单,别 5 步上传
- 正确修复:出 bug 找根因,不只是补丁
6 条都过得了 → 这是个合理的安全设计。任何 1 条 no → 那里有坑。
给客户做安全提案时
客户问”你们怎么保证 formmy.io / xx 系统安全?” —— 用 6 原则回答:
我们按 OWASP 6 原则设计——只保留必要 API、每个客户只能访问自己的数据、5 层独立防御、关键操作多重审批、用户体验流畅不增加无意义复杂度、每次 incident 都做根因分析。
听起来不像营销话术,因为这是专业安全公司说的话。
一句话总结
6 原则不是”考试要点”,是”决策清单”。
设计任何安全方案时,过一遍这 6 条:
- 我减少了攻击者的目标吗?
- 我给了刚好够用的权限吗?
- 我有多层独立防御吗?
- 关键操作能多人参与吗?
- 我的设计够简单到能维护吗?
- 我修的是根因还是症状?
6 个都能回答 yes → 合理设计。任何一个 no → 那里有漏洞。
配套阅读
- 课程评测主页 → Play It Safe Manage Security Risks 风险管理实战
- 同课程深度文 → CISSP 8 域 — 一张能在工作中用的安全活动定位地图
- CIA 实战 → CIA Triad 实战 — 从能说到能用