HTML源码检查是Web安全审计的基础入口，需重点审查meta标签、注释、data-*属性、href/src硬编码URL及动态DOM插入点，结合JS调用链与后端校验验证，覆盖输入-处理-输出全链路。
HTML应用本身不执行逻辑，但它是所有Web安全问题的“呈现层入口”。真正的风险不在标签语法，而在用户输入如何进入、被如何处理、最终怎样输出——评估必须围绕这三点展开，否则只是在检查排版。
查HTML源码里藏了什么敏感信息
很多漏洞线索就明晃晃写在源码里，只是没人翻。打开浏览器开发者工具，按 Ctrl+U 或右键“查看页面源代码”，重点扫以下位置：
-
<meta name="generator">标签：暴露CMS或框架版本，比如name="generator" content="WordPress 5.2.1"，立刻查对应版本已知漏洞 -
<!-- 注释 -->：开发人员常把测试账号、临时API密钥、内部路径写在里面，比如<!-- debug: api-key=sk_test_abc123 --> -
data-*属性：前端组件常用它传参，但有时会塞进未脱敏的用户ID、权限标识甚至token片段 -
href和src中的硬编码URL：看有没有指向测试环境、内网地址（如http://192.168.1.100/api）或未授权的CDN
盯紧所有动态插入DOM的位置
DOM型XSS不是服务器返回的，而是前端JS自己搞出来的。搜索页面加载的所有JS文件，重点关注以下函数调用是否接收了用户可控数据：
-
innerHTML、outerHTML：只要右侧值含location.search、location.hash、document.referrer或localStorage读取的内容，基本就是高危点 -
document.write()：现代项目已少见，但老系统里仍存在，且几乎无法防御 -
eval()、setTimeout(string, ...)、setInterval(string, ...)：如果字符串拼接了URL参数或API响应字段，风险极高 -
<script src="...">动态生成：检查是否用url + '?v=' + Math.random()这类方式拼接，可能被污染成javascript:alert(1)
验证所有表单提交的真实防护能力
前端的 required、pattern、maxlength 全是摆设。真正要验证的是后端是否做了等价校验：
立即学习“前端免费学习笔记（深入）”；
- 用浏览器开发者工具禁用JS，再填一个超长用户名（比如500字符）、SQL注入载荷（
' OR '1'='1）、XSS payload（<img src=x onerror=alert(1)>），直接提交 - 用Burp Suite拦截请求，修改
Content-Type为text/plain或application/json，看后端是否仍能正确解析并校验 - 检查登录、密码重置等关键表单是否有
input[type="hidden"]存放token或状态，尝试篡改其值，看是否被服务端校验 - 上传文件时绕过前端
accept="image/*"，改成.html或.js文件，看后端是否只校验扩展名、是否检测文件头（magic bytes）
检查响应头与CSP策略是否真生效
很多团队配了CSP却没效果，原因往往是策略太宽或没覆盖全部上下文。打开开发者工具的“网络”面板，选任意一个HTML响应，看响应头和 <meta http-equiv="Content-Security-Policy">：
- 是否存在
X-Frame-Options或Content-Security-Policy: frame-ancestors？没有就存在Clickjacking风险 - CSP中
script-src是否包含'unsafe-inline'或'unsafe-eval'？有就等于没开 - 检查
img-src是否限制了data:和javascript:协议，防止通过<img src="data:text/html,...>绕过 - 用
curl -I http://yoursite.com验证生产环境响应头是否与本地开发一致，CDN或反向代理可能覆盖了后端设置
最常被忽略的一点：HTML安全不是单点任务。一个 innerHTML 漏洞可能被CSP拦住，但若同时存在服务端模板注入（SSTI）或JSONP接口，攻击链就能闭环。排查必须横向拉通——从URL参数、AJAX响应、富文本编辑器内容，到iframe嵌入和多媒体标签的src属性，每个数据出口都要问一句：它最终怎么落到DOM里？谁控制了它的源头？
