通过 innerHTML 引发 XSS 及其预防方法

设置 el.innerHTML = userInput 会将字符串解析为 HTML。如果 userInput 包含 <script> 标签或事件处理程序属性（onclick、onerror），浏览器就会解释它们，从而在页面上执行攻击者控制的代码。

任何将用户数据插入 HTML 的代码——无论是服务器模板还是客户端渲染——只要没有对数据进行转义，就存在 XSS 风险。当 API 响应包含用户内容时，从 API 响应构建 innerHTML 的单页应用尤其容易受到攻击。

通过 div.innerHTML = `Welcome, ${user}` 设置用户名 "Bob<img src=x onerror=alert(1)>" 时，图像加载失败会执行 alert(1)。同样的内容如果作为纯文本通过 textContent 设置，则不会造成危害——浏览器看到的只是字符，而不是标签。

textContent 只设置文本——HTML 特殊字符会以字面字符显示，绝不会被当作标签。这在 90% 的情况下都是正确的工具。只有在确实需要渲染标记而不是文本时，才切换到 innerHTML。

要使用用户数据创建元素，请通过 createElement 和 textContent 构建：const li = document.createElement("li"); li.textContent = name; ul.appendChild(li);。结果在结构上与 innerHTML 完全相同，但从构建方式上就能确保 XSS 安全。

对于服务器生成的可信 HTML（您自己的模板输出，或来自可信编辑器且已清理的富文本），使用 innerHTML 没有问题。对于来自不可信来源的数据，未经清理绝不能直接使用它。

如果用户提交富文本（例如评论编辑器内容或 Markdown 渲染结果），请在设置 innerHTML 前进行清理：el.innerHTML = DOMPurify.sanitize(richHtml)。DOMPurify 会移除危险的标签和属性，同时保留 <b>、<em>、<a> 等安全格式。

el.insertAdjacentHTML("beforeend", html) 会解析 HTML 字符串，因此与 innerHTML 面临相同的 XSS 攻击面。规则也相同：绝不要直接传入用户数据；请进行清理或使用 DOM 方法。document.write 也是如此，不过现在不应该再使用它了。

React、Vue、Svelte 和 Angular 默认都会转义插值文本——{name} 是安全的。它们提供了绕过机制（React 中的 dangerouslySetInnerHTML、Vue 中的 v-html），但同样存在 XSS 风险；请谨慎使用，并配合清理。

即使属性值也可能成为攻击途径：<a href={url}> 中的 url="javascript:alert(1)" 会在点击时执行。请逐个协议验证 URL，在将用户输入放入 href、src 或其他承载 URL 的属性之前，只允许使用 http:、https:、mailto: 和 tel:。

现代浏览器支持 Trusted Types：使用 require-trusted-types-for 'script' 配置 CSP 后，innerHTML 会拒绝原始字符串，只有经过策略封装的值才能通过。这通过 API 机制而不是依靠开发规范来防止 XSS。

单个防护层都不够。请结合使用：在服务器上验证输入，在渲染时转义输出，使用 CSP 阻止注入脚本，使用可信类型拒绝原始字符串，并对任何 innerHTML 的使用进行安全审查。分层防御即使其中一层存在错误也能继续发挥作用。

对用户输入使用 innerHTML 是经典的 XSS 攻击途径。对于文本，请使用 textContent；对于结构，请使用 createElement+textContent；需要富 HTML 时，请使用 DOMPurify。对于属性值，请验证 URL 方案。通过叠加 CSP 和可信类型，来化解那些漏过代码审查的错误。现代框架默认会进行转义——请尽量少用它们不安全的绕过机制，并对其进行审查。