应用风险常藏在“功能本身能用，但特定条件下越权或泄露”的细节里。只依赖线上防护，可能漏掉业务逻辑缺陷；只做代码测试，也未必能还原真实部署环境。Web应用防护与代码安全测试的协同流程，重点是让测试发现的问题进入防护策略，并用线上信号反过来补充测试。
先分清两类手段各自看得到什么
代码安全测试检查源代码、依赖和应用行为，适合在开发与发布阶段发现输入校验缺失、权限判断遗漏、危险组件版本等问题。它能追到代码位置，便于修复，但测试质量受覆盖范围、配置和测试数据影响，未必能覆盖真实流量、代理配置或所有业务路径。
线上防护部署在应用运行链路中，可根据请求特征、速率或访问规则拦截部分攻击，也能在暂时无法立即修改代码时降低暴露面。但它通常看不到完整业务语义：如果用户通过合法接口访问了不属于自己的记录，单靠通用规则未必识别得出。两者不是替代关系，API安全和威胁建模可帮助确定需要重点验证的接口与权限边界。
用一条业务链路贯通测试与防护
以密码重置为例梳理风险
密码重置通常会经过身份核验、验证码或令牌校验、设置新密码等步骤。测试时要确认令牌是否限时、能否重复使用，以及重置后旧会话如何处理；同时检查接口是否验证当前操作对象。线上则可关注短时间内重复请求、异常失败增长等信号，并设置与业务规则相符的速率限制。限流过严可能阻断正常用户，因此应结合实际访问模式调整，而不是照搬固定阈值。
把发现、修复、验证串成闭环
- 列出关键资产与边界：按登录、权限变更、数据读取和文件处理等功能列出入口，标明用户、服务和数据之间的访问关系。
- 把风险变成测试项：为每项风险写出可复现的正向与反向条件。例如，用户甲请求用户乙的记录时，应验证服务端拒绝访问，而不只检查页面是否隐藏入口。
- 分层执行检查：在提交和构建阶段运行代码分析及依赖检查；在测试环境对已部署应用执行动态验证，并由人工复核复杂权限与业务流程。渗透测试适合进一步验证攻击链，但不能代替持续的日常检查。
- 部署防护并观察误报：将已确认的攻击模式转为线上规则或告警，先确认规则作用范围，再观察正常请求是否受影响。对拦截记录保留必要的请求特征，避免记录密码、令牌等敏感值。
- 让线上发现回到测试：出现异常告警或新的业务路径时，补充回归用例，修复后验证代码行为与线上规则是否一致，并记录责任人与复查时间。
用场景决定先做什么
新功能发布前，应优先完成权限边界测试、依赖风险检查和关键流程验证；已有应用遇到无法立即修复的问题，可先通过线上规则缩小暴露面，同时明确临时措施的复核期限。规则适用于稳定、可明确识别的请求特征；代码修复更适合解决根因，例如服务端缺少对象级权限检查。Web应用防护与代码安全测试的协同流程，应以修复根因为主、运行时防护为补充，并以回归测试确认问题没有再次出现。
常见问题
线上规则能替代代码修复吗？
不能。规则可暂时降低部分风险，但可能漏掉变体或误伤正常访问，应安排代码修复和后续验证。
每次发布都要做完整渗透测试吗？
不必把完整测试作为每次发布的唯一门槛。常规发布可运行自动化检查和重点回归；重大权限调整或高风险改动，再安排更深入的人工测试。
怎样判断协同流程是否有效？
检查已发现问题是否有责任人、修复记录和回归用例，并确认线上告警能关联到具体功能与处置结果，而非只统计告警数量。
