
本文讲解为何不应使用正则表达式清洗 html,推荐采用专业 html 消毒库(如 dompurify 或 sanitize-html),并提供完整、安全、可落地的前端与后端协同过滤方案。
HTML 是一种嵌套结构复杂、语法灵活(如自闭合标签、CDATA、注释、命名空间等)的标记语言。试图用正则表达式匹配并剔除“非白名单标签”看似简洁,实则隐患重重——例如你的正则 /]*>/g 会在以下场景失效:
- 匹配 失败(因 script 不在否定列表开头,但 可能被误判为结束标签);
- 无法识别
中的 > 被包裹在属性值内,导致提前截断;
- 忽略 HTML 注释 、CDATA 区段或 SVG 内联标签;
- 对大小写不敏感处理缺失(如 );
- 更严重的是:正则无法解析 DOM 结构,无法防范基于标签嵌套、事件属性(onerror)、伪协议(javascript:)等的 XSS 攻击。
✅ 正确做法:使用专为 HTML 净化设计的成熟库。
✅ 推荐方案:DOMPurify(前端首选)
DOMPurify 是由 Cure53 团队维护的、经严格安全审计的轻量级库,支持白名单机制,自动处理转义、属性过滤、SVG 安全策略等:
const allowedTags = ['a', 'b', 'i', 's', 'u', 'sup', 'sub', 'strong', 'cite', 'code', 'del', 'em'];
const cleanHTML = DOMPurify.sanitize(dirtyHTML, {
ALLOWED_TAGS: allowedTags,
// 可选:限制 a 标签仅允许 href(且自动校验为安全协议)
ALLOWED_ATTR: ['href'],
FORBID_ATTR: ['onerror', 'onclick', 'javascript:', 'data-*'], // 显式禁止危险属性
KEEP_CONTENT: true // 移除非允许标签时保留其文本内容(对应示例中 span 的 "without any errors")
});
// 输入示例将被安全净化为:
// "TestPassedwithout any errorsclick here"⚠️ 注意:KEEP_CONTENT: true 是实现你示例中 without any errors → "without any errors" 的关键配置,它确保被移除标签的子文本不丢失。
✅ 后端必须同步消毒(不可省略!)
前端净化仅用于用户体验优化与基础防护;攻击者可绕过 JS 直接提交恶意 payload。因此服务端必须独立执行同等强度的消毒:
立即学习“前端免费学习笔记(深入)”;
- Node.js:继续使用 sanitize-html(更细粒度配置)或 DOMPurify(服务端需搭配 JSDOM);
- PHP:使用 Symfony HtmlSanitizer(v6.2+ 内置,支持白名单 + 属性控制 + XSS 防御);
- Python:推荐 bleach(基于 html5lib,支持白名单与 CSS 过滤);
- Java:使用 OWASP Java HTML Sanitizer。
示例(Symfony PHP):
use Symfony\Component\HtmlSanitizer\HtmlSanitizer;
use Symfony\Component\HtmlSanitizer\Rule\TagRule;
$sanitizer = new HtmlSanitizer([
(new TagRule('a'))->withAllowedAttributes(['href']),
// 允许的标签列表...
new TagRule('b'), new TagRule('i'), /* ... */
]);
$clean = $sanitizer->sanitize($userInput);✅ 总结:安全 HTML 过滤的黄金法则
- ❌ 永远不要用正则表达式解析/修改 HTML;
- ✅ 前端用 DOMPurify 实现即时、用户友好的白名单过滤;
- ✅ 后端必须用语言原生消毒库做最终校验,且策略应与前端一致(避免“信任前端输出”);
- ✅ 白名单优先:只允许明确需要的标签和属性,其余一律拒绝;
- ✅ 敏感属性(如 href, src)需额外校验协议(仅允许 http://, https://, mailto: 等);
- ✅ 日志记录非法输入,用于安全审计与规则迭代。
遵循以上实践,你不仅能精准达成“保留 等标签、剥离











