防XSS核心是检查用户输入是否被安全输出：用F12 Elements搜索<script>、onerror=等关键词，重点审查innerHTML、document.write等危险操作；防Clickjacking需查响应头是否有X-Frame-Options或frame-ancestors；敏感信息常藏于HTML注释、隐藏元素及script硬编码中。
HTML代码本身不执行逻辑，但它是XSS、Clickjacking、信息泄露等漏洞的直接载体——检测关键不在“语法对不对”，而在“用户输入怎么出来”“响应头有没有设”“隐藏内容藏了什么”。
怎么看用户输入是否被安全输出（防XSS核心）
所有动态插入HTML的内容，只要来源是用户可控的（GET参数、表单提交、API返回值），就必须检查它最终如何落到页面上。
- 用浏览器开发者工具（F12）→ Elements 面板，搜索
<script>、onerror=、javascript:等关键词，看是否原样出现在DOM里 - 重点检查这些位置：
innerHTML = user_input、document.write(user_input)、eval()、setTimeout(user_input) - 如果用了
textContent或框架如 React 的{userInput}（非 dangerouslySetInnerHTML），通常已做转义，风险低 - 测试时别只输
<script>alert(1)</script>，试试<img src=x onerror=alert(1)>或大小写混写<ScRiPt>，绕过弱过滤
怎么查响应头是否缺失防框架策略（防Clickjacking）
服务器没配 X-Frame-Options 或 Content-Security-Policy 的 frame-ancestors，页面就可能被恶意网站用 <iframe> 嵌套，诱导用户点击看不见的按钮。
- 在开发者工具 → Network → 选任意HTML请求 → Headers → Response Headers，查找是否有
X-Frame-Options: DENY或Content-Security-Policy: frame-ancestors 'none' - 没有？立刻本地建个测试页：
<iframe src="目标网址" width="100%" height="500"></iframe>，打开看是否能加载成功 -
X-Frame-Options已被部分新浏览器弃用，优先用frame-ancestors；若需兼容旧环境，两者可共存
怎么挖HTML里藏着的敏感信息（常被忽略）
开发人员常把调试信息、临时注释、隐藏元素当成“用户看不到”，但源码一查全暴露。
立即学习“前端免费学习笔记（深入）”；
- 右键 → “查看网页源代码”（不是Elements面板），全局搜索：
<!--、debug=、test=、password、api_key、TODO - 检查
<meta name="generator">、<meta name="description">，可能泄露CMS版本或内部路径 - 找
style="display:none"、class="hidden"、aria-hidden="true"包裹的内容，里面可能有测试账号、未删的API地址 - 注意
<script>标签内硬编码的配置对象，比如window.config = { apiHost: "https://dev-api.example.com" }
为什么手动看比扫工具更有效（新手易错点）
自动化扫描器（如ZAP、Burp）能抓响应头和基础XSS，但对富文本、JS动态渲染、条件性插入等内容识别率低，且容易漏掉注释和隐藏结构。
- 工具不会告诉你
<div id="temp-debug">{ "token": "abc123" }</div>是谁加的、为什么没删 - 工具难以判断
innerHTML插入的是用户昵称还是评论全文——后者风险高得多 - 很多真实漏洞出现在“看似无害”的组合里：比如后端对输入做了
htmlspecialchars()，但前端又用innerHTML渲染，等于白干 - 真正有效的检测，是边看源码边问自己：“这个值从哪来？经过哪些处理？最后在哪显示？上下文是什么？”
最常被跳过的一步，是确认输出上下文——同一段用户输入，在 <div>xxx</div> 里和在 <input value="xxx"> 里，需要的转义方式完全不同；而多数新手只记住了“要转义”，却没记住“在哪转、怎么转”。
