innerHTML直接拼接用户输入必然导致XSS，因浏览器会将其作为HTML解析并立即执行onerror、javascript:等恶意代码；即使使用正则转义，

为什么innerHTML直接拼接用户输入必然出事

因为浏览器会把字符串当作HTML重新解析，onerror、javascript:、data:这些值一旦出现在最终DOM里，就可能立即执行。哪怕你只漏掉一个iframe[sandbox]或a[href]没校验协议，攻击者就能绕过所有前端过滤。

• 不要用innerHTML = userInput，哪怕加了正则替换——、、都会被解析成
• 不要相信“只过滤<script></script>就行”，一样触发
• 服务端转义（如html.escape()）和前端textContent必须同时存在：前者防模板直出漏洞，后者防JS动态渲染漏洞

DOMPurify配置白名单时最常漏的三类属性

很多人以为配了ALLOWED_TAGS就安全了，其实ALLOWED_ATTRIBUTES才是高危区。DOMPurify默认禁用script等标签，但不会自动限制属性值协议或格式。

• a[href]必须配合ADD_URI_SAFE_ATTR并显式声明只允https://、/、#开头，否则href="javascript:fetch('/api/leak')"照常运行
• img[src]同理，要禁用data:和vbscript:协议，且alt属性不能省——漏配会导致img被当成空标签绕过校验
• iframe即使不在ALLOWED_TAGS里，若sandbox被单独放进ALLOWED_ATTRIBUTES，就会启用沙箱逃逸能力，反而扩大攻击面

id/name属性污染全局作用域的真实风险

这不是理论漏洞，是浏览器默认行为：一加载，window.fetch就变成那个DOM节点，后续所有fetch()调用都会报错或静默失败。React/Vue组件里不暴露全局变量，但原生JS页面中极易中招。

htmlppt.skill

把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。

下载

• 服务端渲染时，对用户输入的id、name值强制加前缀，比如user_或哈希后缀id="user_f8a2b"
• 前端动态插入必须用document.createElement('div') + el.setAttribute('id', userInput)，绝不能el.innerHTML += '
  '
• 禁用document.write()——它会触发二次HTML解析，让id/name挂载逻辑重复执行，污染概率翻倍

白名单+DOMPurify ≠ 安全闭环，绕过点在哪

很多人把DOMPurify.sanitize(dirty)结果赋给innerHTML就以为万事大吉，其实只要后续操作踩中任意一条，整个防护就失效。

• 净化后的字符串如果又被拼进模板引擎（如
  ${sanitized}
  ），而模板关闭了转义（{{ content | safe }}），等于跳过净化层
• 把净化结果传给eval()、setTimeout()、location.href或Function()，这些API会重新激活JS执行上下文
• CSP无法拦截onerror或javascript:伪协议，所以白名单漏配一个属性，CSP就完全失效；反过来，白名单再严，没配Content-Security-Policy响应头，base标签仍可劫持所有相对URL