最常见、最危险的XSS漏洞源头是用户输入被直接插入HTML而未转义；需警惕innerHTML、document.write()、eval()及模板字符串拼接，检查搜索回显、URL参数、评论渲染等场景是否转义，优先用测试。
检查用户输入是否被直接插入HTML而未转义
这是XSS漏洞最常见、最危险的源头。只要看到 innerHTML、document.write()、eval() 或模板字符串中拼接用户数据，就要立刻警惕。
常见错误现象包括：搜索关键词回显不转义、URL参数（如 ?msg=hello）直接写入页面、评论内容未经处理就渲染。
- 用浏览器开发者工具查看元素，确认用户可控内容是否以纯文本形式存在（如
<script></script>被原样保留而非变成<script>） - 测试载荷优先用
<img src="x" onerror="alert(1)" alt="如何对HTML页面进行深度安全检测" >，它比<script></script>更容易绕过简单正则过滤 - 注意输出上下文：插在属性里（
value="xxx"）要用属性级编码，插在JS字符串里（var msg = "xxx";）要用JS字符串转义
扫描隐藏元素与隐蔽链接
攻击者常把恶意链接或跳转逻辑藏在看似无害的位置，仅靠肉眼审查极易遗漏。
静态分析必须覆盖：<!-- 注释 -->、display:none 或 visibility:hidden 的元素、color: #fff; background: #fff 的“白字白底”文本、含零宽字符（\u200b）的标签名或属性值。
立即学习“前端免费学习笔记（深入）”；
- 用
grep -r "display:none\|visibility:hidden\|color:#fff" *.html快速定位可疑样式 - 检查所有
<a href></a>、<iframe src></iframe>、<script src></script>，特别留意短链接、非标准端口（如:3001）、随机域名（如abc123xyz.net） - 动态行为不能只看源码：用 Puppeteer 或 Playwright 启动无头浏览器，执行 JS 后再抓取最终 DOM，捕获 AJAX 加载或
document.createElement生成的内容
验证 meta 标签与注释中的敏感信息泄露
开发人员常在 <meta name="generator">、<meta name="description"> 或 HTML 注释里留下调试线索，这些是渗透初期的关键突破口。
典型泄露内容包括：CMS 版本（WordPress 6.5.3）、后端框架（Express 4.18.2）、内部路径（/api/v2/internal/）、测试账号（admin:test123）。
- 用
curl -s URL | grep -i -E "(generator|description|keywords|author)"批量提取 - 不要忽略注释里的 TODO、FIXME、DEBUG 标记，它们可能暴露未清理的调试接口或硬编码密钥
- 检查
<meta http-equiv="refresh">是否被用于跳转到恶意站点
识别前端参与SQL注入的数据流动路径
HTML 页面本身不执行 SQL，但它是攻击链的起点。关键在于确认前端是否把未经校验的用户输入，原样塞进 API 请求参数或表单字段中。
例如：一个搜索框提交 /api/search?q=1%27%20OR%20%271%27=%271，而后端又没做参数化查询，这就是完整攻击路径。
- 用浏览器开发者工具的 Network 面板，筛选 XHR/Fetch 请求，检查所有
GET参数和POSTbody 中是否包含用户输入且无过滤 - 重点盯防字段名含
id、user_id、order_by、limit的请求 —— 这些最易被用于注入 - 若发现前端用正则限制输入（如
/^[a-zA-Z0-9_]+$/），别以为安全：后端仍必须独立校验，因为正则可被绕过（如用 Unicode 等价字符）
真正难的不是找到某处 innerHTML，而是确认它是否真的接收了外部输入；不是看到一个注释，而是判断它是否指向仍在运行的测试环境。所有检测动作都要带着「这个数据从哪来、到哪去、中间有没有可信边界」的链条意识，否则很容易停在表面。
