XSS是唯一真正由HTML层面直接引发的安全漏洞，核心在于用户可控数据未经转义即拼入HTML（如innerHTML、URL参数反射、表单回显等），攻击者可通过<img src=x onerror=alert(1)>等载荷触发执行。
HTML 本身不执行逻辑，但漏洞常出现在“用户输入如何被插入到 HTML 中”这个环节——XSS 是唯一真正由 HTML 层面直接引发的安全问题，其他如 SQL 注入、CSRF 等需后端配合才能利用，但前端暴露的模式会成为攻击入口。
怎么确认页面是否存在 XSS 漏洞
核心判断依据：用户可控的数据（表单提交、URL 参数、localStorage 读取值等）是否未经转义就拼接到 HTML 中。常见高危位置包括：
-
innerHTML = userInput或document.write(userInput) - URL 参数直接写入
<script src="xxx?param=<user_input>"> - 表单回显时未对
value或placeholder做属性值转义 - 富文本编辑器输出未启用白名单过滤（如直接用
v-html渲染未净化内容）
实操建议：在输入框或地址栏中尝试提交 <img src=x onerror=alert(1)>，提交后打开开发者工具 Elements 面板，搜索该字符串是否原样出现在 DOM 中；若弹窗或 DOM 中存在未闭合标签、事件属性，则已触发 XSS。
为什么 textContent 比 innerHTML 安全
textContent 将内容作为纯文本插入，浏览器不会解析其中任何标签或属性；而 innerHTML 会触发 HTML 解析流程，把字符串当作标记语言重新构建 DOM 节点。
立即学习“前端免费学习笔记（深入）”；
容易踩的坑：
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 误以为 “只插在
div里就安全” —— 只要用了innerHTML，哪怕父容器是div，<script>或onerror仍可执行 - 用正则替换
<script>却漏掉大小写变体（<ScRiPt>）、注释绕过（<!-- --><script>）或 Unicode 编码混淆 - 服务端做了转义，但前端 JS 又用
innerHTML二次拼接，导致“转义被绕过”
示例对比：
const userInput = '<img src=x onerror=alert(1)>'; <p>// ❌ 危险 el.innerHTML = userInput; // 弹窗触发</p><p>// ✅ 安全（仅显示文字） el.textContent = userInput; // 页面显示：<img src=x onerror=alert(1)>
哪些 HTML 属性容易被用于 XSS 利用
除 script、iframe 外，以下属性只要值来自用户输入且未校验，就可能成为 XSS 入口：
-
onerror、onload、onclick等所有以on开头的事件处理器 -
href中的javascript:伪协议（<a href="javascript:alert(1)">） -
src和data属性指向恶意 URL（如远程 JS 文件） -
style中的expression()（IE 旧版）或url(javascript:...)（部分 CSS 引擎）
关键原则：任何属性值若拼接了用户输入，必须做两件事：
① 对特殊字符进行 HTML 实体编码（< → ，<code>" → "）；
② 若为 URL 类属性（href、src），额外校验协议白名单（仅允许 http://、https://、/、# 等）。
W3C 验证器和 CSP 能否替代手动检查
不能。W3C 验证器只检查语法合规性，对 XSS 零检测能力；CSP（Content-Security-Policy）是纵深防御手段，能阻断外链脚本执行，但无法防止 DOM-based XSS（如 location.hash 触发的 eval()）或内联事件执行（除非配置 'unsafe-inline' 被禁用且无 nonce/hash）。
真正有效的组合是：
- 服务端输出时统一使用框架内置转义（如 Django 的
{{ value|escape }}、PHP 的htmlspecialchars()） - 前端 JS 中严格区分
textContent/setAttribute()（用于属性）和innerHTML（仅用于可信富文本） - 对动态插入的 HTML，必须用 DOMPurify 等库做白名单净化，而非简单 replace
- CSP 作为兜底：至少设置
default-src 'self'; script-src 'self' 'unsafe-inline'并逐步移除unsafe-inline
最容易被忽略的一点：很多团队花大力气配好 CSP，却在 JS 里写了 eval(atob(location.hash.substr(1))) —— 这类代码完全绕过 CSP，且 W3C 验证器根本看不到。
