富文本场景下服务端HTML过滤不可省略,PHP必须用HTMLPurifier或XssHtml类做最终净化,前端DOMPurify仅作体验优化;需配置白名单、禁用危险协议、显式禁止script等标签,并在入库和渲染时双重净化。
富文本场景下,不做服务端 HTML 过滤 = 默认开放 XSS 入口。前端用 DOMPurify 或 sanitizeHTML 只是体验优化,绕过它发个 POST 请求,恶意标签照进数据库、照渲染。
别信 strip_tags() 或 htmlspecialchars() 能搞定富文本——前者删不干净属性(比如 <a href="javascript:alert(1)">),后者直接把整个 HTML 当纯文本转义,用户发的加粗、链接全变源码。
HTMLPurifier 是目前 PHP 生态最稳的选择,支持白名单配置、CSS 属性控制、URI 协议校验,还能修复畸形 HTMLXssHtml 类,注意它依赖 DOMDocument,对 malformed HTML 容错强,但不兼容 IE6 及更老浏览器(现在基本不是问题)'URI.AllowedSchemes' => ['http', 'https', 'mailto'],否则 javascript:、data: 仍可能漏掉style 被清空?不是 bug,是默认策略。要保留 background-size 得开 'CSS.AllowTricky' => true 并在 'CSS.AllowedProperties' 里手动加进去用户粘贴一段带 <script> 的 HTML,DOMPurify.sanitize() 确实能当场干掉。但攻击者根本不会走你这一步。
ALLOWED_TAGS,必须配 FORBID_TAGS: ['script', 'iframe', 'object', 'embed'],双重保险href 不光看标签,还得用 DOMPurify.isValidAttribute('a', 'href', value) 单独校验,否则 href="javascript:" 这种编码可能漏判v-html 绑定未净化内容,React 别碰 dangerouslySetInnerHTML —— 即使你刚调过 DOMPurify,也要确保变量来源可信监听 input 事件实时清理非法字符,对用户体验有帮助,但和安全无关。
立即学习“前端免费学习笔记(深入)”;
<img src=x onerror=alert(1)>,除非你把整段 HTML 拿去跑一遍 DOMPurify(性能爆炸,不现实)keydown 或 paste 替代 input?更糟——paste 拦不住拖放,keydown 拦不住右键粘贴、自动填充、语音输入submit 时,取 textarea.value 跑一次轻量 DOMPurify.sanitize()(仅限展示预览),然后立刻把原始值发给后端——后端才是唯一可信的净化环节最常被忽略的一点:富文本字段入库前,必须走服务端净化;渲染到页面时,若用 innerHTML 插入,得再过一遍 DOMPurify(哪怕刚入库时已过滤过)——因为中间可能被其他模块误改、或 DB 被绕过直写。信任链不能断在任何一环。