直接用innerHTML渲染用户输入是XSS高危入口，因浏览器会执行onclick、onerror等合法属性；安全做法是富文本必须经DOMPurify等白名单库净化，且需显式限制URI协议与禁用危险属性，前后端净化策略须严格对齐。

直接用 innerHTML 渲染用户输入就是 XSS 入口

别信“我只显示评论，没用 script 标签就没事”这种想法。浏览器不区分你“想不想执行”，只要语法合法，onclick、onerror、href="javascript:" 这些属性在 innerHTML 里照常触发。

常见错误现象包括：

• 用户发一条

  点我

  ，别人一划过就删数据
• 评论里贴了个 ，静默加载远程脚本
• 大小写绕过：<script>alert(1)</script> 被简单正则漏掉

真正安全的做法是：富文本必须走 DOM 解析 + 白名单过滤，不是字符串替换。用 textContent 只能保纯文本；要保留 、 等格式，就得靠 DOMPurify 这类库做结构级校验。

DOMPurify 配置不设 ALLOWED_URI_REGEXP 就等于没设

默认配置下，DOMPurify.sanitize() 允许 href="javascript:alert(1)" 和 src="data:text/html;base64,..."，这不是疏忽，是设计使然——它把协议校验交给你自己决定。

必须显式限制 URI 协议，否则所有常见 XSS 绕过都成立：

• ALLOWED_URI_REGEXP: /^https?:\/\//i 是最稳妥的写法（比 ALLOWED_PROTOCOLS 更防绕过）
• 如果业务真需要 mailto: 或 tel:，得单独加进正则，比如 /^(https?|mailto|tel):\/\//i
• FORBID_ATTR: ['onerror', 'onclick', 'onload'] 必须写，不能依赖黑名单默认值
• lang 和 dir 属性要放进 ALLOWED_ATTR，否则多语言内容会丢失语义

服务端净化不能省，且必须和前端白名单对齐

前端 JS 可被禁用、绕过或直接删掉，所以服务端过滤不是“可有可无的补充”，而是强制防线。用 strip_tags() 或正则删标签？不行——它不管属性、不校验嵌套、放过

使用华数设计生成高保真HTML原型、演示文稿、动画和设计评审

使用经过文档化的设计技能，从真实的品牌或项目背景中生成HTML原生原型、幻灯片、动态演示、可视化图表和评审流程。

下载

，还可能破坏实体编码（比如把 © 变成乱码）。

正确做法是：

• PHP 项目用 HTMLPurifier，并确保其 HTML.Allowed 配置和前端 ALLOWED_TAGS 字段级一致
• Java 项目用 jsoup 的 Whitelist 模式，或 OWASP Java HTML Sanitizer
• Node.js 推荐 sanitize-html，注意它默认不处理 on* 属性，需手动开启 allowedAttributes 控制
• 前后端白名单必须完全相同：比如前端允许 a，后端就不能只放行 p 和 br

marked 解析 Markdown 后必须接 DOMPurify，不能信 sanitize: false

marked.parse() 输出的是原始 HTML 字符串，不是“已消毒”的安全内容。v4.3+ 版本里 sanitize: false 不代表“放心用”，它只是关掉那个早已废弃、毫无防护能力的内置过滤器。

典型错误链：

• 写 el.innerHTML = marked.parse(userMd) → 直接执行 XSS
• 加了 sanitize: false 还不接 DOMPurify → 和没加一样
• 动态加载 .md 文件时用 fetch('./doc.md').then(r => r.json()) → 报错静默失败，因为 .md 不是 JSON

正确流程只有这一条：先 marked.parse(mdText) 得到 HTML 字符串，再 DOMPurify.sanitize(htmlString) 净化，最后赋给 innerHTML。中间少任何一环，XSS 就在那儿等着。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！