4、安全编码规范：OWASP Top 10、输入验证、输出编码、安全API设计、代码审查要点
安全编码这事儿，说白了就是写代码时得留个心眼。我见过太多团队，功能跑得飞起，安全漏洞却一抓一大把。今天咱们聊聊几个核心要点，都是我这些年踩坑踩出来的经验。
4.1 OWASP Top 10：你的安全必修课
OWASP Top 10 是什么？就是全球公认的 Web 应用十大安全风险。我个人习惯，每接手一个新项目，第一件事就是拿这个清单过一遍。
2021 年的版本里，有几个重点我得提一下：
- A01: 失效的访问控制 —— 说白了就是权限没管好。我遇到过某个系统，普通用户改个 URL 参数就能看到管理员后台，这问题太典型了。
- A03: 注入 —— SQL 注入、命令注入，老生常谈但依然高发。你想想看，直接把用户输入拼到 SQL 里，这不是请黑客喝茶吗？
- A06: 易受攻击和过时的组件 —— 很多团队只管加新功能，不管升级依赖库。我记得有个客户，用的 Log4j 版本还是 1.x，结果 Log4Shell 漏洞一出，整个周末都在打补丁。
核心原则： 别把 OWASP Top 10 当考试题背，要把它当成代码审查的 checklist。每写一段代码，问自己一句：「这个操作会不会触发 Top 10 里的某一条？」
4.2 输入验证：信任是漏洞的温床
永远不要相信用户的输入。这是我做安全以来最深刻的体会。
输入验证分两个层面：
- 白名单验证 —— 只允许符合规则的输入。比如手机号，就只允许数字和特定格式。这是最安全的方式。
- 黑名单验证 —— 拦截已知的恶意字符。比如过滤掉
<script>。但说实话，黑名单总有漏网之鱼。
我曾经处理过一个案例：某个电商平台的搜索框，只做了黑名单过滤，结果攻击者用 <img src=x onerror=alert(1)> 绕过去了。嗯，这里要注意，黑名单永远防不住所有花样。
我的建议： 能用白名单就别用黑名单。如果必须用黑名单，至少配合上下文做二次校验。比如邮箱地址，先校验格式，再过滤特殊字符。
4.3 输出编码：把数据变成安全的字符串
输出编码是防止 XSS 攻击的关键。你想想看，用户提交了一段 <script>alert('xss')</script>，如果你直接原样输出到页面上，浏览器就会把它当成代码执行。
正确的做法是：根据输出上下文做编码。
| 输出上下文 | 编码方式 | 示例 |
|---|---|---|
| HTML 标签内容 | HTML 实体编码 | < → < |
| HTML 属性 | 属性编码 | " → " |
| JavaScript 字符串 | Unicode 编码 | < → \u003C |
| URL 参数 | URL 编码 | < → %3C |
我个人习惯用成熟的库来做编码，比如 OWASP 的 Java Encoder 或者 ESAPI。自己手写编码逻辑？别闹了，很容易漏掉边界情况。
避坑指南： 我曾经见过一个团队，在 JavaScript 里用 innerHTML 直接插入用户数据，虽然做了 HTML 编码，但没做 JavaScript 编码。结果攻击者用 \u003C 绕过了过滤。记住：编码必须匹配上下文！
4.4 安全API设计：接口不是越开放越好
API 设计的安全原则，我总结成三条：
- 最小权限原则 —— 每个接口只暴露必要的数据和操作。别图省事，把整个数据库表结构都返回给前端。
- 认证与授权分离 —— 认证是「你是谁」，授权是「你能做什么」。我见过很多 API，认证做得很严，但授权形同虚设，用户 A 能调用用户 B 的数据。
- 限流与防重放 —— 接口要加频率限制，防止暴力破解。同时用时间戳 + nonce 防止重放攻击。
举个例子，一个安全的 API 请求头应该长这样：
POST /api/v1/order
Authorization: Bearer <token>
X-Request-ID: 550e8400-e29b-41d4-a716-446655440000
X-Timestamp: 1712345678
X-Signature: <HMAC-SHA256 of body + timestamp>
Content-Type: application/json
{
"product_id": "12345",
"quantity": 1
}嗯，这里要注意，签名算法一定要用服务端生成的密钥，别把密钥硬编码在客户端代码里。
4.5 代码审查要点：用流程堵住漏洞
代码审查是安全编码的最后一道防线。我建议每个团队都建立安全审查 checklist，至少包含以下内容：
- 输入点检查 —— 所有用户输入（表单、URL 参数、请求头、文件上传）是否都做了验证？
- 输出点检查 —— 所有动态数据输出到页面或 API 时，是否做了正确的编码？
- 权限检查 —— 每个敏感操作是否都校验了用户权限？
- 依赖检查 —— 引入的第三方库是否有已知漏洞？版本是否最新？
- 错误处理 —— 异常信息是否暴露了敏感数据（如堆栈跟踪、数据库结构）？
我的经验： 代码审查别只看代码逻辑，还要看数据流。从用户输入到数据库存储，再到页面展示，每个环节都可能有漏洞。我曾经用这个思路，在一个看似安全的系统里挖出了 3 个高危漏洞。
最后说一句：安全编码不是一个人的事，是整个团队的习惯。把 OWASP Top 10 贴在墙上，把输入验证写成代码模板，把输出编码做成自动化工具。只有这样，安全才能真正落地。