17370845950

不是必须做HTML实体转义，而是必须防止XSS；应使用HtmlPurifier按白名单过滤富文本，允许安全标签属性，禁用script等危险内容，再存入数据库。

PHP 插入富文本前必须做 HTML 实体转义吗？

不是“必须”做实体转义，而是必须防止 XSS——而转义只是手段之一。直接 htmlspecialchars() 存储富文本会把 变成 zuojiankuohaophpcnstrongyoujiankuohaophpcn，导致前端渲染出纯文本，丢失格式。所以核心矛盾是：既要保留合法 HTML 标签（如

、），又要过滤危险标签（如

用 htmlpurifier 过滤后再插入数据库最稳妥

HtmlPurifier 是 PHP 生态中经过长期验证的富文本 XSS 防御方案，它基于白名单机制，可精确控制允许的标签、属性、CSS、URL 协议等。比手写正则或简单 strip_tags() 安全得多。

实操建议：

• 安装：composer require ezyang/htmlpurifier
• 初始化配置需显式声明允许的标签，例如只允许排版类标签：

  $config = HTMLPurifier_Config::createDefault();
  $config->set('HTML.Allowed', 'p,b,i,u,br,ol,ul,li,a[href|title],img[src|alt|width|height]');
  $purifier = new HTMLPurifier($config);

• 过滤后存入数据库：$clean_html = $purifier->purify($user_input);
• 注意：不要在入库前做 htmlspecialchars()，那会双重编码；也不要对已 purify 过的内容再做转义——它输出的就是安全的 HTML 字符串

为什么不能只用 mysqli_real_escape_string 或 PDO::quote？

mysqli_real_escape_string() 和 PDO::quote() 仅防御 SQL 注入，完全不处理 XSS。它们把 ' 变成 \'，但对 毫无作用。富文本字段若未经 HTML 过滤就直接 echo 到页面，XSS 立刻触发。

常见错误现象：

• 用户提交 → 后端只做了 SQL 转义 → 前端 echo $row['content']; → 弹窗执行
• 用 strip_tags($html, '
  ') 允许 ，但没限制 onmouseover 属性 → 仍可 XSS
• 前端用 v-html 或 innerHTML 渲染未净化内容 → 绕过所有服务端 SQL 防护

存储后输出时还要注意什么？

即使入库前已用 HtmlPurifier 过滤，输出到页面时仍要遵守最小权限原则：

• 如果字段只用于展示（非编辑回填），直接 echo $clean_html; 即可 —— 因为 HtmlPurifier 输出的是已清洗的 HTML
• 如果字段要用于 JS 上下文（比如赋值给 data-content 属性），需额外用 json_encode($clean_html, JSON_UNESCAPED_UNICODE) 包裹，避免引号或

   截断

• 绝对不要在 JS 中拼接未净化的 HTML：el.innerHTML = ''; —— 这等于放弃全部防护
• CDN 或前端缓存可能缓存恶意内容，确保 purify 步骤在缓存生成之前完成

真正容易被忽略的是：HtmlPurifier 的配置不是一劳永逸的。HTML.Allowed 若后期开放了 iframe 或 style，就必须同步评估 CSS 表达式、javascript: 协议等新攻击面。每次放宽白名单，都要重审 XSS 风险。