为什么需要一本安全 Web 工程实战手册？
每次上线前都做安全测试，但漏洞还是反复出现？根本原因往往不是工具不够，而是缺少一份团队共识的安全 Web 工程实战手册。本文不是理论堆砌，而是一份可以直接拿来用的行动指南，帮助你从设计阶段就把风险扼杀在摇篮里。
如果你正在寻找系统化的安全工程方法，可以先浏览我们的 Secure Web Engineering 知识中心，那里有更完整的框架。需要落地执行？我们的 Web 开发服务 团队可以帮你把安全实践嵌入流水线。
四个关键阶段与可执行检查清单
1. 设计阶段：威胁建模先行
别等代码写完了再补安全。在架构评审时，用 STRIDE 或 PASTA 做一次轻量威胁建模。重点识别：
- 认证与授权边界（谁可以做什么？）
- 数据流向与存储（敏感数据在哪里？）
- 外部输入点（所有用户输入都是不可信的）
产出物：一份不超过两页的威胁模型图，标注风险等级与缓解措施。
2. 编码阶段：内置安全控制
- 输入验证：白名单优先，拒绝所有不符合格式的输入。
- 输出编码：根据上下文（HTML、JS、CSS、URL）选择正确的编码函数。
- 参数化查询：永远不要拼接 SQL/NoSQL 查询字符串。
- 依赖管理：使用
npm audit或pip-audit每周扫描一次，高危漏洞 48 小时内升级。
3. 测试阶段：自动化与人工结合
- SAST（静态分析）：每次提交自动扫描，规则集覆盖 OWASP Top 10。
- DAST（动态分析）：在预发布环境每周运行一次，模拟真实攻击。
- 人工代码审查：重点关注认证、授权、加密逻辑。
4. 部署与运维阶段：持续监控
- 最小权限原则：容器、服务账号、API 密钥只给必要权限。
- 日志与告警：记录所有认证事件、权限变更、异常错误，并接入 SIEM。
- 定期密钥轮换：数据库密码、API 令牌每 90 天更换一次。
安全 Web 工程检查清单（可打印）
以下是我们团队在项目中实际使用的检查项，你可以直接复制到你的 Sprint 看板中：
- 威胁模型已创建并评审
- 所有用户输入经过白名单验证
- 输出编码覆盖所有动态内容
- 数据库查询使用参数化接口
- 依赖扫描无高危漏洞（或已制定修复计划）
- SAST 扫描通过，无严重/高危问题
- DAST 扫描通过，无跨站脚本、SQL 注入等问题
- 代码审查覆盖安全敏感模块
- 容器镜像已扫描，无已知漏洞
- 日志记录包含必要安全事件
- 密钥与证书已配置自动轮换
常见问题
问：这套手册适合小团队吗？
答：完全适合。小团队可以优先做威胁建模、输入验证和依赖扫描这三项，投入产出比最高。
问：如何让开发团队接受这些流程？
答：从最痛的点切入——比如先解决依赖漏洞告警，让大家看到效果。然后逐步引入威胁建模，把它变成架构评审的一部分，而不是额外负担。