dangerouslysetinnerhtml 和 v-html 必须配合 dompurify 配置白名单净化，因其绕过框架默认转义，直接执行 html；默认 sanitize 不安全，需显式设置 allowed_tags、allowed_attr 并禁用高危属性与标签。
dangerouslySetInnerHTML 和 v-html 必须配净化，不能只靠框架默认转义
React 的 {userInput} 和 Vue 的 {{ userInput }} 确实会自动转义，但这只覆盖文本内容渲染。一旦你用 dangerouslySetInnerHTML 或 v-html 插入 HTML 字符串，框架的保护就完全失效——恶意脚本会直接执行。
常见错误现象：后端返回一段带 <img onerror="fetch('/steal', {method:'POST',body:document.cookie})"> 的富文本，前端没做任何处理就塞进 dangerouslySetInnerHTML，用户打开页面瞬间 Cookie 就被发走。
- 所有传给
dangerouslySetInnerHTML或v-html的值，必须先过DOMPurify.sanitize() - 不要自己写正则过滤（比如
replace(/<script>/gi, '')</script>），DOMPurify 是基于解析器的白名单机制，能防绕过 - SSR 场景下也要净化：服务端渲染时若拼接了未净化的 HTML，首屏就已存在 XSS 风险
别把 DOMPurify 当“开关”，要配置白名单才真正安全
直接调用 DOMPurify.sanitize(html) 用的是默认配置，它会保留 style、onload、data- 属性等高危项。很多团队踩坑就在这里——以为装了库就万事大吉。
典型风险场景：CMS 返回的 HTML 包含 <div style="background:url(javascript:alert(1))"> 或 <code><img src="https://img.php.cn/?x-oss-process=image/resize,p_40" alt="在React与Vue集成环境中防范HTML代码质量漏洞的最佳实践">，默认净化不拦截。
- 显式配置白名单：
DOMPurify.setConfig({ ALLOWED_TAGS: ['b','i','p','br'], ALLOWED_ATTR: ['class','src'] }) - 禁用内联样式和事件处理器：
FORBID_TAGS: ['style'], FORBID_ATTR: ['onerror','onload','javascript:'] - Vue 项目中建议封装成自定义指令，如
v-safe-html，内部强制调用带配置的DOMPurify.sanitize
React/Vue 混合项目里，HTML 传递路径越多，越容易漏掉净化点
Vue 组件里用 v-html 渲染一段内容，再通过 props 传给 React 子组件，后者又用 dangerouslySetInnerHTML 渲染——这种跨框架流转，极易在中间某一层漏掉净化。
容易忽略的环节：Vuera 或其它桥接库在 Vue → React 数据透传时，不会自动净化；API 响应里的 HTML 字段可能被多个组件复用，但只在一处做了净化。
- 净化动作必须靠近最终渲染点，而不是“上游统一处理一次”
- 如果一个 HTML 字符串被多个组件消费，每个使用方都要独立调用
DOMPurify.sanitize() - 在 TypeScript 中为 HTML 字段加类型标注，比如
type SanitizedHtml = string & { __brand: 'sanitized' }，避免误传未净化内容
SonarJS 能发现哪些 HTML 安全问题，但不能替代运行时防护
SonarJS 可以扫描出 dangerouslySetInnerHTML 的使用位置、是否缺少 DOMPurify 调用、v-html 是否直连 props，但它看不到实际运行时数据流——比如后端接口突然返回了新字段，前端代码没改，但新字段被直接塞进了 v-html。
真实漏洞往往出现在“新增需求”场景：运营要求文章页支持插入广告 div，开发快速用 v-html 渲染后端返回的广告 HTML，忘了加净化。
- 把 SonarJS 集成进 CI，对
dangerouslySetInnerHTML和v-html相关代码行强制要求注释说明净化逻辑 - 在 ESLint 中加自定义规则，禁止
__html:后面直接跟变量名（如__html: rawHtml），必须是__html: DOMPurify.sanitize(rawHtml) - 关键业务页面上线前，用浏览器控制台手动测试：往对应 API 返回里注入
<svg onload="alert(1)"></svg>，看是否弹窗
<a href="https://www.php.cn/link/5097ae38663ea27586f6b57c1f1b9c8a">click</a>。这类问题不会被静态扫描捕获，只能靠运行时净化配置兜底。
