dast不能直接扫生产环境sql注入，因其依赖响应差异判断漏洞，而生产环境关闭错误回显、启用waf、限流防爆破，导致漏报率高且易触发风控封禁ip；必须绕开错误回显缺失、waf拦截、连接池耗尽三大硬限制。
为什么DAST不能直接扫生产环境的SQL注入
DAST工具（比如OWASP ZAP、Burp Suite、IBM AppScan）本质是模拟攻击者发请求，靠观察响应差异（报错、延时、内容变化）来推测漏洞。生产环境通常关闭详细错误信息、启用WAF、限流防爆破，500页面可能被统一重定向，MySQL syntax error这类关键提示根本不会回显——DAST失去判断依据，漏报率陡增。更麻烦的是，真实流量下反复发送' OR '1'='1这种载荷，可能触发风控规则，导致IP封禁或业务误伤。
必须绕开的三个硬限制
不是“能不能扫”，而是“扫了有没有意义”。实际落地前得确认：
-
error_reporting和display_errors在PHP里是否为Off？Java应用的spring.mvc.throw-exception-if-no-handler-found是否设为false？——没错误回显，DAST对基于错误的注入基本失效 - WAF规则里是否包含
sqlmap、UNION SELECT、sleep(等关键词拦截？ZAP默认的Injection扫描策略大概率被拦在第一层 - 数据库连接池是否启用了
maxWait或testOnBorrow？DAST并发探测容易耗尽连接，引发下游服务超时，这不是“发现漏洞”，是制造故障
如果非要上，只允许这三种方式
前提是已获安全与运维双签批，且避开业务高峰（如凌晨2–4点）：
- 用
OWASP ZAP的Passive Scan模式挂载在反向代理后：不主动发包，只分析真实用户流量里的请求/响应，识别id=1'、q=%27%20OR%201%3D1这类可疑参数，适合发现字符型注入痕迹 - 导出一周Nginx/Apache访问日志，用
grep -E "(%27|'|\bunion\b|\bsleep\()"筛出高危请求，人工复现——比盲扫更准，且不扰动系统 - 在灰度节点部署
IAST探针（如Contrast或Seeker），用真实业务测试流量驱动检测：它能看到PreparedStatement是否被绕过、String.format拼接是否流入executeQuery()，定位到行级代码，误报率低于5%
真正该盯住的不是DAST，而是这三处
生产环境SQL注入风险80%来自开发惯性：比如用MyBatis的${xxx}代替#{xxx}，或Spring Data JPA里写@Query(value = "SELECT * FROM user WHERE name = '"+name+"'", nativeQuery = true)。这些DAST永远扫不到，但SAST工具（如SonarQube）配好规则后能100%捕获。别把时间花在让ZAP撞墙，先跑通CI阶段的mvn sonar:sonar检查。
