什么是HTTP参数污染
HTTP参数污染指的是客户端在请求中提交多个同名参数，服务端框架在解析时采取不同的合并策略，导致业务代码拿到的值与预期不一致，从而被攻击者利用的漏洞。它最早在Web安全领域被广泛关注，是因为不同语言、不同框架对重复参数的处理差异极大，攻击者可以借助这种差异绕过输入校验或者防火墙规则。
举例来说，对于请求/transfer?to=alice&to=bob&amount=5000，PHP取最后一个值，ASP.NET将多个值用逗号拼接，而Express的处理方式又有自己的特点。如果前端的校验逻辑、后端的取值逻辑、以及中间的安全设备各自取的值不一样，攻击者就能让校验环节看到的是一个合法值，而业务环节实际使用的是另一个恶意值。
需要注意的是，参数污染不仅出现在查询字符串里，POST表单的body同样存在这个问题，比如表单里出现两个username字段。因此防护时需要同时考虑req.query和req.body两个入口。
Express对重复参数的解析行为
Express底层依赖qs库解析查询字符串。对于重复出现的同名参数，qs默认会将其收集为一个数组。看下面这个例子：
const express = require('express');
const app = express();
app.get('/test', (req, res) => {
console.log(req.query.name);
res.json({ name: req.query.name });
});
app.listen(3000);
// 请求 /test?name=foo&name=bar
// req.query.name 的值是 ['foo', 'bar']，是一个数组上面的例子展示了qs默认将同名参数合并成数组的行为。这种设计本身方便了前端传递数组，但也带来了隐患：如果业务代码假定req.query.name一定是字符串，比如直接拿去做数据库查询或者字符串比较，一旦攻击者传入重复参数，类型就变成了数组，后续逻辑可能产生不可预期的行为，极端情况下会触发报错信息泄露或者查询条件被篡改。
更危险的场景是业务代码中使用了强制取第一个值的写法，例如某些老代码会用req.query.id[0]或者依赖隐式类型转换。攻击者可以精心构造第一个参数通过校验、第二个参数执行恶意逻辑的请求，比如?role=user&role=admin，一旦权限校验代码和实际赋值代码取的下标不同，就会造成越权。理解框架的解析行为是防护的前提，接下来看如何用中间件统一处理。
使用HPP中间件进行防护
hpp是npm上一个专门处理参数污染的Express中间件，体积很小，用法简单。它的核心思路是：遍历req.query中的每个字段，如果某个字段的值是数组，就只保留其中一项（默认最后一项），并把被过滤掉的原始值挂载到req.filteredQuery上，方便需要时排查。
先安装依赖：
npm install hpp
然后在应用中注册，注意要放在所有业务路由之前：
const express = require('express');
const hpp = require('hpp');
const app = express();
// 必须在路由之前注册，建议紧跟在body解析器之后
app.use(express.urlencoded({ extended: false }));
app.use(hpp());
app.get('/search', (req, res) => {
// 经过hpp处理后，req.query.name 一定是字符串
// 请求 /search?name=foo&name=bar 时，name 的值为 'bar'
res.json({ name: req.query.name });
});
app.listen(3000, () => {
console.log('server running on port 3000');
});注册顺序非常关键。如果hpp放在路由之后，请求早已经被业务代码消费，过滤就失去了意义。推荐的位置是在express.urlencoded和express.json之后、所有app.use路由之前，这样所有进入业务层的请求都已经被规范化。
如果业务上确实需要接收数组参数，可以通过白名单告诉hpp哪些字段允许保留数组形式：
app.use(hpp({
whitelist: ['tags', 'ids'] // 这些字段即使重复出现也不会被过滤
}));
// 请求 /list?tags=a&tags=b
// req.query.tags 仍然是 ['a', 'b']，符合业务预期被过滤掉的重复值不会直接丢弃，hpp会把它们保存在req.filteredQuery中。线上出现可疑请求时，可以加一段日志把filteredQuery打印出来，作为安全审计的依据，判断是否有攻击者在试探参数污染漏洞。
补充防护建议与常见误区
HPP中间件解决的是规范化问题，但完整的安全防护还需要配合其他手段。第一，对参数做严格的类型校验，推荐使用Joi或zod等校验库，在Schema中明确声明字段必须是字符串还是数组，类型不符直接拒绝请求，而不是依赖框架的默认行为。第二，body参数同样要处理，如果接口接受JSON格式的请求体，JSON本身允许同名键，解析后的行为也需要验证，必要时在业务层对body做同样的去重逻辑。
第三，不要以为上了hpp就万事大吉。如果攻击面在反向代理层，比如Nginx的参数处理、WAF的取值规则与Node.js不一致，依然可能存在差异利用空间。合理的做法是在入口层直接拒绝包含重复参数的请求，例如在Nginx中通过Lua脚本或者map指令检测参数出现次数，把明显异常的请求在网关就挡掉，Node.js侧再用hpp兜底。
最后提一个常见误区：有些项目把extended设为true时，qs还支持a[0]=x&a[1]=y这种下标语法构造复杂嵌套结构，攻击者可以借此传入超深对象造成性能问题。因此除非确实需要，urlencoded解析建议使用{ extended: false }，配合hpp与输入校验，多层措施叠加才能把参数污染的风险降到最低。
Node.js参数污染HPP中间件Express安全防护修改时间：2026-09-11 15:03:03