这款XSS过滤器的防护效果如何？是否存在绕过方式？

实用性分析 #

你实现的这种字符白名单过滤属于正向输入验证的一种，作为XSS防护的补充手段有一定作用，但实用性非常有限，核心问题在于：

• 误报率过高：你的白名单仅包含字母、数字和@.,!?，大量正常用户输入（比如空格、引号、下划线、冒号、括号等）都会被误拦截，比如带空格的句子、含下划线的邮箱、带括号的备注内容都无法通过，严重影响用户体验；
• 防护范围狭窄：仅检查req.body的内容，完全没覆盖URL参数、Cookie、HTTP请求头等其他可能的输入源；
• 依赖输出防护：即使通过了该中间件的检查，如果后端输出时没有正确转义，理论上仍有风险，但由于白名单限制极严，这种风险极低。

可能的绕过途径 #

虽然你的白名单限制较严，但仍存在一些潜在的绕过场景：

• 未覆盖的输入源：该中间件只校验请求体内容，如果后端将URL参数、Cookie或HTTP头中的值直接插入页面，这些输入不受白名单约束，可能被用来构造XSS；
• 请求体解析漏洞：如果后端使用的请求体解析库存在编码处理缺陷，比如某些特殊编码的恶意字符未被正确解码，而编码后的字符恰好落在白名单范围内，可能绕过检查（这种情况非常罕见，依赖特定解析库的漏洞）；
• 业务逻辑拼接风险：如果后端将多个通过白名单检查的输入片段拼接后，在特定输出上下文形成可执行的恶意代码（不过由于你的白名单不含冒号、括号，这种场景几乎不可能发生）。

补充建议 #

既然你已经在使用HTML转义库，建议以输出转义作为核心防护手段，输入验证仅作为辅助：

• 放宽白名单范围，允许正常的用户输入字符（比如空格、引号、下划线等），避免误报；
• 确保所有输入源（包括URL参数、Cookie等）都被覆盖，或统一通过输出转义处理；
• 根据输出上下文选择合适的转义规则（比如HTML内容转义HTML实体，JS内容转义JS字符串等）。

内容的提问来源于stack exchange，提问作者galdinotrashaj