打开一个电商网站，网页在搜索框里敲入 `' OR '1'='1`，漏洞回车。扫描页面没报错，网页反而把后台所有商品数据吐了出来——这不是漏洞电影桥段，是扫描去年某中型商城真实发生的漏洞。网页漏洞扫描干的网页就是这种事：用自动或手动的方式，找出网站里那些能被恶意输入撬开的漏洞裂缝。

很多人以为扫描就是扫描跑个工具，等报告。网页真不是漏洞。工具能告诉你“这里可能有SQL注入”，扫描但到底能不能利用、网页影响范围多大，漏洞得靠人去验证。扫描我见过扫描器报了一百多个“高危”，结果八成是误报——参数里带个单引号就触发规则，实际后端做了预编译，根本注不进去。反过来，有些逻辑漏洞扫描器压根扫不出来，比如修改一下URL里的订单ID就能看到别人的收货地址。这种得靠手工测。

常见的扫描目标分几类。注入类最经典，SQL注入、命令注入、LDAP注入，核心都是没过滤用户输入。XSS跨站脚本也类似，往评论区塞一段 ``，如果页面直接渲染出来，那就中招了。还有文件包含、目录遍历、CSRF、SSRF……名字听着唬人，本质都是“信任了不该信任的数据”。

工具方面，AWVS、Burp Suite、OWASP ZAP 是主流。Burp 的爬虫加主动扫描，配合 Repeater 手动改包，基本能覆盖八成场景。但别迷信自动化。有次我扫一个前后端分离的站点，工具爬不到任何API接口，因为路由全是JS动态生成的。最后是打开浏览器开发者工具，把XHR请求一条条复制到Burp里测的。扫描器再强，也模拟不了人点按钮、填表单、翻页那套操作。

扫描之前得想清楚边界。生产环境直接跑全量扫描，轻则拖慢数据库，重则触发WAF封IP。我习惯先在测试环境跑一遍，确认漏洞存在后再去生产环境做最小化验证——比如只发一个探测请求，看返回包差异。还有，扫描需要授权。没拿到书面许可就去扫别人的站，哪怕只是看看，也可能踩法律红线。

扫描报告别只盯着“高危”两个字。一个反射型XSS，如果只在登录后的个人中心出现，危害远小于未授权就能触发的SQL注入。得结合业务场景判断。另外，修复建议要具体。别写“对输入进行过滤”，要写“在`/api/search`接口的`keyword`参数处，用白名单限制只允许字母数字和空格，长度不超过50”。开发看了才知道怎么改。

最后说个观察：很多漏洞反复出现，不是技术难，是流程缺位。开发图快，直接字符串拼接SQL；测试只点功能，不测异常输入；上线前没人做安全卡点。扫描能发现漏洞，但堵不住漏洞。真正管用的，是把安全扫描嵌到CI/CD里，每次提交代码自动跑一遍SAST，上线前再跑DAST。工具是死的，流程是活的。

下次你看到一个搜索框，不妨想想：如果我在里面输入奇怪的东西，后端会怎么处理？这个念头，就是漏洞扫描的起点。