简介前端开源库-xss-filters是一份面向前端开发者与安全入门者的XSS防护工具源码包用于解决用户输入在页面输出时可能被注入恶意脚本的问题。资源共30个文件以20个js源码与测试脚本为主体辅以3个json配置、3个md说明文档另有yml、license等辅助文件压缩包约66KB体积轻量便于集成。内容涵盖核心过滤逻辑、单元测试、模糊测试用例及多版本压缩产物可帮助读者理解HTML标签、属性、URL与CSS等场景的转义与清理策略并支持按项目需求自定义过滤规则。目前已有617人学习下载适合希望掌握防御性编程、降低XSS漏洞风险的前端工程师参考也可作为安全编码实践的入门素材。1. 前端开源库 xss-filters把用户输入塞进 DOM 之前先过一遍这道滤网做前端的人迟早会撞上 XSS。你从接口拿到一段用户昵称顺手innerHTML塞进页面本地跑得好好的上线第二天安全同学甩过来一条告警某条昵称里带了img srcx onerror...页面一加载就执行了。这类问题不是靠“我小心一点”能解决的得靠一层稳定的过滤逻辑。xss-filters 就是干这个的前端开源库——它把不可信数据按输出上下文做转义让你在拼 HTML、写属性、塞 URL 的时候有个统一的出口。它适合谁适合那些还在用字符串拼接渲染、又不想引入整套框架级防护的团队也适合想搞明白“转义到底在转什么”的初中级前端。这篇不聊虚的从它解决什么问题讲到怎么接进项目、参数怎么传、哪些坑我踩过。2. xss-filters 的上下文转义逻辑为什么不能一把梭哈2.1 转义的本质是“看菜下饭”很多人对 XSS 防护的理解停留在“把换成lt;”。这个做法在纯 HTML 文本节点里没问题但换个场景就翻车。比如你要把用户输入拼进href转义了没用攻击者用javascript:alert(1)照样能点。再比如拼进onclick这种事件属性转义规则又不一样。xss-filters 的核心思路就是不同输出位置用不同的转义函数。它提供的函数大致分几类输出位置对应函数处理对象HTML 文本内容inHTMLData标签之间的文本HTML 属性值inHTMLAttr双引号包裹的属性单引号属性值inSingleQuotedAttr单引号包裹的属性无引号属性值inUnQuotedAttr裸属性值URL 参数uriInHTMLData/uriInHTMLAttr拼进链接的查询串JS 字符串inScriptDatascript 标签内的字符串这个设计的好处是逼你思考“我现在到底在哪个上下文”。我见过太多项目全局挂一个escapeHtml结果在 URL 场景下形同虚设。xss-filters 不给你这种偷懒的机会用哪个函数取决于你把数据放哪。2.2 它和框架自带防护的区别Vue、React 默认会对插值做转义但它们的防护边界在“模板语法内”。一旦你用v-html、dangerouslySetInnerHTML或者手动document.write框架就不管了。xss-filters 的定位是补这个缺口——它不依赖框架纯函数你可以在任何地方调用。另一个区别是它处理的是字符串级转义不是 DOM 级净化。像 DOMPurify 那种库是把一整段 HTML 解析后过滤标签适合“允许部分富文本”的场景。xss-filters 更适合“我只要纯文本任何标签都不许有”的场景。选型时先想清楚你要的是白名单富文本还是彻底禁止标签前者用 DOMPurify后者用 xss-filters 更轻。2.3 引入方式与基本调用它是老牌库支持 CommonJS 和 AMD也能直接 script 引入。现代项目里我一般这样接# 通过包管理器安装注意包名 npm install xss-filters// 按需引入具体函数避免整包打进去 const { inHTMLData, inHTMLAttr, uriInHTMLData } require(xss-filters); // 场景一把用户昵称渲染到标签之间 const nickname img srcx onerroralert(1); const safeNickname inHTMLData(nickname); // 输出lt;img srcx onerroralert(1)gt; document.getElementById(name).innerHTML safeNickname; // 场景二拼进 href 的查询参数 const keyword scriptalert(1)/script; const safeKeyword uriInHTMLData(keyword); const link /search?q${safeKeyword}; // 此时 keyword 里的特殊字符已被 URI 编码无法闭合属性或注入标签逻辑说明inHTMLData会把、、、、等字符转成实体确保内容只能作为文本显示。uriInHTMLData先做 URI 编码再处理 HTML 实体保证拼进 URL 时不会破坏结构。参数方面这些函数都只接受一个字符串参数传null或undefined会返回空字符串不会抛异常——这点在接口字段可能为空时很省心。提示不要对已经转义过的字符串再转一次lt;会被转成amp;lt;页面上就会显示成lt;而不是。转义只做一次在数据进入 DOM 之前做。3. 把 xss-filters 接进真实渲染流程从接口到 DOM 的完整链路3.1 数据流梳理在哪一层做过滤我一般把过滤放在“数据即将进入 DOM 的那一层”而不是接口返回就立刻转。原因很简单同一份数据可能被用在多个上下文接口层转义了后面想拼进 URL 就得多一次解码反而乱。正确做法是数据保持原始状态在渲染函数里按上下文调用对应过滤器。以一个搜索建议列表为例链路是这样的// 假设从接口拿到原始数据 const rawData { keyword: b测试/b, url: /detail?id1namescript, count: 10 }; // 渲染函数里按位置分别处理 function renderSuggestion(item) { // 文本节点用 inHTMLData const safeKeyword inHTMLData(item.keyword); // 属性值用 inHTMLAttr假设属性用双引号包裹 const safeUrl inHTMLAttr(item.url); return li>const { inHTMLData, inHTMLAttr, uriInHTMLData } require(xss-filters); // 定义每个字段的过滤策略 const filterMap { title: inHTMLData, author: inHTMLData, avatar: inHTMLAttr, profileUrl: inHTMLAttr, searchQuery: uriInHTMLData }; function safeRender(template, data) { const filtered {}; Object.keys(data).forEach(key { const filter filterMap[key]; // 没有配置策略的字段默认按 HTML 文本处理 filtered[key] filter ? filter(String(data[key])) : inHTMLData(String(data[key])); }); // 这里用简单的占位符替换实际项目可换成模板引擎 return template.replace(/\{\{(\w)\}\}/g, (_, k) filtered[k] || ); } const tpl div classcardimg src{{avatar}}a href{{profileUrl}}{{title}}/aspan{{author}}/span/div; const html safeRender(tpl, { title: scriptalert(1)/script, author: A同学, avatar: x onerroralert(1), profileUrl: /user?id1 });逻辑说明filterMap把字段和过滤函数绑定新增字段时只要加一行配置。safeRender遍历数据对每个字段调用对应过滤器没有配置的走默认inHTMLData。这样即使漏配也不会完全裸奔。参数上String(data[key])是为了防止数字、布尔值传进过滤器时报错——虽然库本身能处理但显式转换更稳。注意这个safeRender只是演示思路生产环境如果模板复杂建议用成熟模板引擎的转义机制xss-filters 作为补充。不要自己写正则解析 HTML那是另一个坑。3.3 和构建工具配合按需打包xss-filters 的包不大但如果只用其中两三个函数全量引入还是浪费。用 ES module 的按需导入配合 webpack 或 rollup 的 tree-shaking// 只导入用到的函数 import { inHTMLData, inHTMLAttr } from xss-filters; // 使用 const safe inHTMLData(userInput);如果项目用的是老版本构建工具不支持 tree-shaking可以直接引具体文件路径视包结构而定或者用require(xss-filters/lib/inHTMLData)这种形式。具体路径以实际安装后的目录为准装完看一眼node_modules/xss-filters的结构就清楚了。参数配置上这个库没有全局配置项所有行为由你调用的函数决定。这意味着没有“配置错了导致全局失效”的风险但也意味着每个调用点都得自己负责。我一般会在代码规范里加一条任何innerHTML赋值右侧必须出现 xss-filters 的函数调用code review 时重点看这个。4. 避坑与排查那些让我加班到凌晨的 XSS 过滤问题4.1 现象转义后页面显示lt;而不是原因对已经转义过的数据重复调用了inHTMLData。比如接口返回的字段本身已经存了lt;你又转一次被转成amp;最终渲染出来就是lt;的字面量。解决明确数据在链路中的状态。如果接口返回的是原始数据在渲染层转一次如果接口已经转过渲染层不要再转。我一般要求后端返回原始数据转义统一在前端做避免两边都转导致双重转义。4.2 现象URL 里的参数被截断后面的内容丢失原因把uriInHTMLData的结果直接拼进href时如果没做 HTML 属性转义可能被浏览器解析为实体起始符。比如?a1b2里的b可能被当成实体。解决拼进属性的 URL先用uriInHTMLData处理参数值再用inHTMLAttr处理整个 URL 字符串。两步顺序不能反先 URI 编码再 HTML 属性转义。const rawParam a1bscript; const uriSafe uriInHTMLData(rawParam); // 先 URI 编码 const attrSafe inHTMLAttr(/search?${uriSafe}); // 再属性转义 // 最终拼进 href${attrSafe}4.3 现象在onclick里拼用户数据转义了还是能执行原因事件属性里的 JS 上下文和 HTML 属性上下文不同。inHTMLAttr处理的是 HTML 层面的引号闭合但onclickdoSomething(用户输入)里用户输入如果包含或\可能逃逸出 JS 字符串。解决尽量避免在事件属性里拼用户数据。如果非要做用inScriptData处理 JS 字符串部分同时外层用inHTMLAttr。更好的做法是用addEventListener绑定事件数据通过dataset传递彻底避开内联事件。4.4 现象过滤后的数据在eval或setTimeout字符串里仍然执行原因xss-filters 防的是 HTML 注入不是 JS 代码注入。如果你把用户输入拼进eval、setTimeout(...)、new Function里转义 HTML 实体没用因为 JS 引擎不认 HTML 实体。解决永远不要把用户输入拼进动态执行的 JS 代码。如果业务需要动态逻辑用白名单映射比如用户传type1你映射到预定义的函数而不是直接执行用户给的字符串。4.5 现象某些老浏览器里转义结果异常原因xss-filters 依赖一些字符串 API极老的浏览器比如 IE8 及以下可能不支持。虽然现在很少遇到但如果项目有兼容要求得测。解决确认目标浏览器范围。如果需要兼容 IE8可能得引入 polyfill 或者换用更保守的手写转义函数。不过说实话现在还在支持 IE8 的项目XSS 可能不是最紧迫的问题。5. 进阶用法把 xss-filters 包成团队规范里的强制层5.1 用 ESLint 插件卡住裸奔的 innerHTML光靠自觉不行我后来在团队里加了一条 ESLint 规则检测到innerHTML、outerHTML、insertAdjacentHTML赋值时如果右侧没有出现 xss-filters 的函数调用就报 warning。实现方式可以写一个简单的自定义规则或者用no-restricted-syntax匹配 AST。// .eslintrc.js 片段示意 module.exports { rules: { no-restricted-syntax: [ warn, { selector: AssignmentExpression[left.property.nameinnerHTML], message: innerHTML 赋值前请确认已用 xss-filters 处理数据 } ] } };这条规则不能百分百拦住所有情况但能提醒开发者“这里有个安全决策点”。配合 code review基本能堵住大部分低级错误。5.2 写一个统一的 DOM 写入函数更彻底的做法是封装一个safeSetHTML内部强制走过滤const { inHTMLData } require(xss-filters); function safeSetText(el, text) { // 纯文本场景用 textContent 最安全不需要转义 el.textContent text; } function safeSetHTML(el, html) { // 如果确实需要渲染 HTML调用方必须自己保证 html 已过滤 // 这里只做一层兜底把非字符串转成字符串 el.innerHTML String(html); } // 对外暴露的 API 只允许传纯文本 // 需要富文本的场景走单独的审核流程逻辑说明textContent本身就会把内容当纯文本处理不需要额外转义性能也好。大部分“我要显示用户输入”的场景其实用textContent就够了根本不需要innerHTML。只有确实要渲染带标签的内容时才走innerHTML并且必须经过 xss-filters 或 DOMPurify。5.3 验证过滤是否生效的土办法改完代码怎么确认真的防住了我一般用几个固定 payload 手动测测试输入预期结果scriptalert(1)/script页面上显示文本不弹窗img srcx onerroralert(1)属性不被闭合不弹窗javascript:alert(1)链接不可点击执行 onmouseoveralert(1)单引号属性不被逃逸把这些 payload 存成一个测试用例文件每次改渲染逻辑就跑一遍。有条件的可以接进自动化测试用 jsdom 模拟 DOM 环境断言输出。5.4 什么时候该换方案xss-filters 适合“纯文本输出”场景。如果你的业务需要允许用户提交带格式的内容比如富文本编辑器它就不够用了——你需要的是 DOMPurify 这类能解析 HTML 并过滤标签的库。我一般这样分纯文本字段用 xss-filters富文本字段用 DOMPurify两者不冲突按字段类型选。从那以后我每次接新项目第一件事就是在渲染层把 xss-filters 的函数挂上去然后写一条 ESLint 规则卡住innerHTML。这个习惯帮我省掉了至少三次安全告警。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/15 18:41:01 · 阅读 1.2k 前端XSS防护实战：xss-filters上下文转义与DOM安全渲染指南
简介前端开源库-xss-filters是一份面向前端开发者与安全入门者的XSS防护工具源码包用于解决用户输入在页面输出时可能被注入恶意脚本的问题。资源共30个文件以20个js源码与测试脚本为主体辅以3个json配置、3个md说明文档另有yml、license等辅助文件压缩包约66KB体积轻量便于集成。内容涵盖核心过滤逻辑、单元测试、模糊测试用例及多版本压缩产物可帮助读者理解HTML标签、属性、URL与CSS等场景的转义与清理策略并支持按项目需求自定义过滤规则。目前已有617人学习下载适合希望掌握防御性编程、降低XSS漏洞风险的前端工程师参考也可作为安全编码实践的入门素材。1. 前端开源库 xss-filters把用户输入塞进 DOM 之前先过一遍这道滤网做前端的人迟早会撞上 XSS。你从接口拿到一段用户昵称顺手innerHTML塞进页面本地跑得好好的上线第二天安全同学甩过来一条告警某条昵称里带了img srcx onerror...页面一加载就执行了。这类问题不是靠“我小心一点”能解决的得靠一层稳定的过滤逻辑。xss-filters 就是干这个的前端开源库——它把不可信数据按输出上下文做转义让你在拼 HTML、写属性、塞 URL 的时候有个统一的出口。它适合谁适合那些还在用字符串拼接渲染、又不想引入整套框架级防护的团队也适合想搞明白“转义到底在转什么”的初中级前端。这篇不聊虚的从它解决什么问题讲到怎么接进项目、参数怎么传、哪些坑我踩过。2. xss-filters 的上下文转义逻辑为什么不能一把梭哈2.1 转义的本质是“看菜下饭”很多人对 XSS 防护的理解停留在“把换成lt;”。这个做法在纯 HTML 文本节点里没问题但换个场景就翻车。比如你要把用户输入拼进href转义了没用攻击者用javascript:alert(1)照样能点。再比如拼进onclick这种事件属性转义规则又不一样。xss-filters 的核心思路就是不同输出位置用不同的转义函数。它提供的函数大致分几类输出位置对应函数处理对象HTML 文本内容inHTMLData标签之间的文本HTML 属性值inHTMLAttr双引号包裹的属性单引号属性值inSingleQuotedAttr单引号包裹的属性无引号属性值inUnQuotedAttr裸属性值URL 参数uriInHTMLData/uriInHTMLAttr拼进链接的查询串JS 字符串inScriptDatascript 标签内的字符串这个设计的好处是逼你思考“我现在到底在哪个上下文”。我见过太多项目全局挂一个escapeHtml结果在 URL 场景下形同虚设。xss-filters 不给你这种偷懒的机会用哪个函数取决于你把数据放哪。2.2 它和框架自带防护的区别Vue、React 默认会对插值做转义但它们的防护边界在“模板语法内”。一旦你用v-html、dangerouslySetInnerHTML或者手动document.write框架就不管了。xss-filters 的定位是补这个缺口——它不依赖框架纯函数你可以在任何地方调用。另一个区别是它处理的是字符串级转义不是 DOM 级净化。像 DOMPurify 那种库是把一整段 HTML 解析后过滤标签适合“允许部分富文本”的场景。xss-filters 更适合“我只要纯文本任何标签都不许有”的场景。选型时先想清楚你要的是白名单富文本还是彻底禁止标签前者用 DOMPurify后者用 xss-filters 更轻。2.3 引入方式与基本调用它是老牌库支持 CommonJS 和 AMD也能直接 script 引入。现代项目里我一般这样接# 通过包管理器安装注意包名 npm install xss-filters// 按需引入具体函数避免整包打进去 const { inHTMLData, inHTMLAttr, uriInHTMLData } require(xss-filters); // 场景一把用户昵称渲染到标签之间 const nickname img srcx onerroralert(1); const safeNickname inHTMLData(nickname); // 输出lt;img srcx onerroralert(1)gt; document.getElementById(name).innerHTML safeNickname; // 场景二拼进 href 的查询参数 const keyword scriptalert(1)/script; const safeKeyword uriInHTMLData(keyword); const link /search?q${safeKeyword}; // 此时 keyword 里的特殊字符已被 URI 编码无法闭合属性或注入标签逻辑说明inHTMLData会把、、、、等字符转成实体确保内容只能作为文本显示。uriInHTMLData先做 URI 编码再处理 HTML 实体保证拼进 URL 时不会破坏结构。参数方面这些函数都只接受一个字符串参数传null或undefined会返回空字符串不会抛异常——这点在接口字段可能为空时很省心。提示不要对已经转义过的字符串再转一次lt;会被转成amp;lt;页面上就会显示成lt;而不是。转义只做一次在数据进入 DOM 之前做。3. 把 xss-filters 接进真实渲染流程从接口到 DOM 的完整链路3.1 数据流梳理在哪一层做过滤我一般把过滤放在“数据即将进入 DOM 的那一层”而不是接口返回就立刻转。原因很简单同一份数据可能被用在多个上下文接口层转义了后面想拼进 URL 就得多一次解码反而乱。正确做法是数据保持原始状态在渲染函数里按上下文调用对应过滤器。以一个搜索建议列表为例链路是这样的// 假设从接口拿到原始数据 const rawData { keyword: b测试/b, url: /detail?id1namescript, count: 10 }; // 渲染函数里按位置分别处理 function renderSuggestion(item) { // 文本节点用 inHTMLData const safeKeyword inHTMLData(item.keyword); // 属性值用 inHTMLAttr假设属性用双引号包裹 const safeUrl inHTMLAttr(item.url); return li>const { inHTMLData, inHTMLAttr, uriInHTMLData } require(xss-filters); // 定义每个字段的过滤策略 const filterMap { title: inHTMLData, author: inHTMLData, avatar: inHTMLAttr, profileUrl: inHTMLAttr, searchQuery: uriInHTMLData }; function safeRender(template, data) { const filtered {}; Object.keys(data).forEach(key { const filter filterMap[key]; // 没有配置策略的字段默认按 HTML 文本处理 filtered[key] filter ? filter(String(data[key])) : inHTMLData(String(data[key])); }); // 这里用简单的占位符替换实际项目可换成模板引擎 return template.replace(/\{\{(\w)\}\}/g, (_, k) filtered[k] || ); } const tpl div classcardimg src{{avatar}}a href{{profileUrl}}{{title}}/aspan{{author}}/span/div; const html safeRender(tpl, { title: scriptalert(1)/script, author: A同学, avatar: x onerroralert(1), profileUrl: /user?id1 });逻辑说明filterMap把字段和过滤函数绑定新增字段时只要加一行配置。safeRender遍历数据对每个字段调用对应过滤器没有配置的走默认inHTMLData。这样即使漏配也不会完全裸奔。参数上String(data[key])是为了防止数字、布尔值传进过滤器时报错——虽然库本身能处理但显式转换更稳。注意这个safeRender只是演示思路生产环境如果模板复杂建议用成熟模板引擎的转义机制xss-filters 作为补充。不要自己写正则解析 HTML那是另一个坑。3.3 和构建工具配合按需打包xss-filters 的包不大但如果只用其中两三个函数全量引入还是浪费。用 ES module 的按需导入配合 webpack 或 rollup 的 tree-shaking// 只导入用到的函数 import { inHTMLData, inHTMLAttr } from xss-filters; // 使用 const safe inHTMLData(userInput);如果项目用的是老版本构建工具不支持 tree-shaking可以直接引具体文件路径视包结构而定或者用require(xss-filters/lib/inHTMLData)这种形式。具体路径以实际安装后的目录为准装完看一眼node_modules/xss-filters的结构就清楚了。参数配置上这个库没有全局配置项所有行为由你调用的函数决定。这意味着没有“配置错了导致全局失效”的风险但也意味着每个调用点都得自己负责。我一般会在代码规范里加一条任何innerHTML赋值右侧必须出现 xss-filters 的函数调用code review 时重点看这个。4. 避坑与排查那些让我加班到凌晨的 XSS 过滤问题4.1 现象转义后页面显示lt;而不是原因对已经转义过的数据重复调用了inHTMLData。比如接口返回的字段本身已经存了lt;你又转一次被转成amp;最终渲染出来就是lt;的字面量。解决明确数据在链路中的状态。如果接口返回的是原始数据在渲染层转一次如果接口已经转过渲染层不要再转。我一般要求后端返回原始数据转义统一在前端做避免两边都转导致双重转义。4.2 现象URL 里的参数被截断后面的内容丢失原因把uriInHTMLData的结果直接拼进href时如果没做 HTML 属性转义可能被浏览器解析为实体起始符。比如?a1b2里的b可能被当成实体。解决拼进属性的 URL先用uriInHTMLData处理参数值再用inHTMLAttr处理整个 URL 字符串。两步顺序不能反先 URI 编码再 HTML 属性转义。const rawParam a1bscript; const uriSafe uriInHTMLData(rawParam); // 先 URI 编码 const attrSafe inHTMLAttr(/search?${uriSafe}); // 再属性转义 // 最终拼进 href${attrSafe}4.3 现象在onclick里拼用户数据转义了还是能执行原因事件属性里的 JS 上下文和 HTML 属性上下文不同。inHTMLAttr处理的是 HTML 层面的引号闭合但onclickdoSomething(用户输入)里用户输入如果包含或\可能逃逸出 JS 字符串。解决尽量避免在事件属性里拼用户数据。如果非要做用inScriptData处理 JS 字符串部分同时外层用inHTMLAttr。更好的做法是用addEventListener绑定事件数据通过dataset传递彻底避开内联事件。4.4 现象过滤后的数据在eval或setTimeout字符串里仍然执行原因xss-filters 防的是 HTML 注入不是 JS 代码注入。如果你把用户输入拼进eval、setTimeout(...)、new Function里转义 HTML 实体没用因为 JS 引擎不认 HTML 实体。解决永远不要把用户输入拼进动态执行的 JS 代码。如果业务需要动态逻辑用白名单映射比如用户传type1你映射到预定义的函数而不是直接执行用户给的字符串。4.5 现象某些老浏览器里转义结果异常原因xss-filters 依赖一些字符串 API极老的浏览器比如 IE8 及以下可能不支持。虽然现在很少遇到但如果项目有兼容要求得测。解决确认目标浏览器范围。如果需要兼容 IE8可能得引入 polyfill 或者换用更保守的手写转义函数。不过说实话现在还在支持 IE8 的项目XSS 可能不是最紧迫的问题。5. 进阶用法把 xss-filters 包成团队规范里的强制层5.1 用 ESLint 插件卡住裸奔的 innerHTML光靠自觉不行我后来在团队里加了一条 ESLint 规则检测到innerHTML、outerHTML、insertAdjacentHTML赋值时如果右侧没有出现 xss-filters 的函数调用就报 warning。实现方式可以写一个简单的自定义规则或者用no-restricted-syntax匹配 AST。// .eslintrc.js 片段示意 module.exports { rules: { no-restricted-syntax: [ warn, { selector: AssignmentExpression[left.property.nameinnerHTML], message: innerHTML 赋值前请确认已用 xss-filters 处理数据 } ] } };这条规则不能百分百拦住所有情况但能提醒开发者“这里有个安全决策点”。配合 code review基本能堵住大部分低级错误。5.2 写一个统一的 DOM 写入函数更彻底的做法是封装一个safeSetHTML内部强制走过滤const { inHTMLData } require(xss-filters); function safeSetText(el, text) { // 纯文本场景用 textContent 最安全不需要转义 el.textContent text; } function safeSetHTML(el, html) { // 如果确实需要渲染 HTML调用方必须自己保证 html 已过滤 // 这里只做一层兜底把非字符串转成字符串 el.innerHTML String(html); } // 对外暴露的 API 只允许传纯文本 // 需要富文本的场景走单独的审核流程逻辑说明textContent本身就会把内容当纯文本处理不需要额外转义性能也好。大部分“我要显示用户输入”的场景其实用textContent就够了根本不需要innerHTML。只有确实要渲染带标签的内容时才走innerHTML并且必须经过 xss-filters 或 DOMPurify。5.3 验证过滤是否生效的土办法改完代码怎么确认真的防住了我一般用几个固定 payload 手动测测试输入预期结果scriptalert(1)/script页面上显示文本不弹窗img srcx onerroralert(1)属性不被闭合不弹窗javascript:alert(1)链接不可点击执行 onmouseoveralert(1)单引号属性不被逃逸把这些 payload 存成一个测试用例文件每次改渲染逻辑就跑一遍。有条件的可以接进自动化测试用 jsdom 模拟 DOM 环境断言输出。5.4 什么时候该换方案xss-filters 适合“纯文本输出”场景。如果你的业务需要允许用户提交带格式的内容比如富文本编辑器它就不够用了——你需要的是 DOMPurify 这类能解析 HTML 并过滤标签的库。我一般这样分纯文本字段用 xss-filters富文本字段用 DOMPurify两者不冲突按字段类型选。从那以后我每次接新项目第一件事就是在渲染层把 xss-filters 的函数挂上去然后写一条 ESLint 规则卡住innerHTML。这个习惯帮我省掉了至少三次安全告警。希望帮到你。本文还有配套的精品资源点击获取