浏览器开发者工具是查找HTML漏洞的起点，必须通过Elements面板观察浏览器自动修正的DOM结构、Console验证DOM型XSS、Network分析表单提交与响应头（如X-Frame-Options、CSP）缺失，暴露真实运行时风险。
直接用浏览器开发者工具查HTML漏洞，不是“能查”，而是“必须从这里开始”。它不提供全自动报告，但能暴露所有被浏览器修正的结构错误、被JavaScript篡改的DOM、未转义的用户输入、以及被隐藏但实际存在的敏感字段——这些恰恰是大多数XSS、Clickjacking、隐藏字段篡改和表单绕过漏洞的起点。
看Elements面板里浏览器“偷偷修了什么”
浏览器遇到不合法HTML（比如未闭合的<p>、<div>嵌套在<p>里），会自动重排DOM树。这种“修复”本身就是漏洞信号：
- 打开开发者工具，切到
Elements面板，逐层展开，留意缩进异常或被自动包裹的节点（例如你写的<p>文字<div>块</div></p>，浏览器可能把它改成<p>文字</p><div>块</div>） - 右键某个元素，选“Edit as HTML”，手动删掉一个
</div>再回车，观察DOM是否立刻补全——说明原始HTML本就残缺 - 注意灰色文字或带删除线的标签：它们是被浏览器忽略或降级处理的（如
<font>在现代HTML中已废弃，但若仍存在，可能暴露老旧、未维护的代码路径）
在Console里模拟XSS payload验证DOM型漏洞
DOM型XSS不发请求、不经过服务器，只靠前端JS把location.search或location.hash拼进innerHTML就触发。用Console快速验证：
- 在地址栏加测试参数，比如
?q=<img+src=x+onerror=alert(1)> - 切到
Console，执行document.querySelector('div#result').innerHTML，看返回值是否包含未转义的<img标签 - 搜索页面JS中是否调用了
innerHTML、document.write、eval或setTimeout，再用console.log打点，确认其参数是否来自location、localStorage等不可信源
用Network面板抓表单提交，看服务端是否信任前端验证
前端required、pattern、maxlength全是摆设。真正的问题是服务端接不接受绕过后的数据：
立即学习“前端免费学习笔记（深入）”；
- 在
Network面板勾选“Preserve log”，提交一次正常表单 - 找到对应的
POST请求，右键→“Copy”→“Copy as cURL”，粘贴到终端，把某个price字段改成负数或超长字符串，再执行 - 如果响应状态是
200且返回成功页，或返回错误但没校验逻辑（比如只提示“格式错误”却不拒绝），说明服务端没做校验 - 特别检查
hidden字段：在Elements里找到<input type="hidden" name="role" value="user">，右键“Edit attribute”，改成admin，再提交，看后端是否照单全收
检查Response Headers找框架嵌入与CSP缺失
Clickjacking和XSS防护依赖HTTP响应头，而不是HTML内容本身：
- 在
Network面板点任意主文档请求（通常是第一个document类型），切换到Headers→Response Headers - 查找
X-Frame-Options：值为DENY或SAMEORIGIN才算有效；若缺失，或值为ALLOW-FROM（已弃用），则存在框架嵌入风险 - 查找
Content-Security-Policy：重点看是否有frame-ancestors 'none'或script-src 'self'；若整行缺失，或script-src含'unsafe-inline'，XSS防护形同虚设 - 不要只信HTML里的
<meta http-equiv="Content-Security-Policy">——它优先级低于响应头，且可被JS覆盖
开发者工具不是万能扫描器，但它暴露的是真实运行时状态。最常被忽略的，是把Elements里看到的“修正后DOM”当成原始HTML，或者只盯着Console报错却不管Network里服务端怎么处理数据。漏洞不在代码写得有多丑，而在浏览器和服务器之间那层信任是否被滥用了。
