Node ExpressJS中间件处理路由与直接定义路由的风险差异

现有两种实现回顾 #

第一种：router.use手动判断路径 #

router.use((req, res, next) => {
    if(req.originalUrl == '/api/test'){
        //does stuff
        res.send(result);
    }
    next();
})

第二种：官方route方法注册路由 #

route.get('/api/test', (req, res) => {
   //does stuff
   res.send(result)
})

第一种写法的核心问题 #

1. 响应后调用next()引发的不可控风险 #

Express中res.send执行后就已经向客户端发送了响应头和响应体，此时仍然调用next()会继续执行后续所有中间件、路由逻辑：

• 轻则触发Cannot set headers after they are sent to the client报错，导致服务异常
• 重则如果后续中间件存在权限校验、响应头修改、日志写入等逻辑，会出现权限绕过、响应内容被篡改、日志记录异常等不可预估的安全问题

2. 路径匹配逻辑不严谨的安全漏洞 #

使用req.originalUrl == '/api/test'做全等匹配的逻辑存在大量疏漏：

• req.originalUrl包含查询字符串，用户请求/api/test?id=1时会匹配失败，导致业务逻辑不执行
• 无法自动处理URL编码、尾斜杠、大小写差异问题，攻击者可通过/api/%74est、/api/test/、/API/TEST等路径绕过匹配，若该路由存在权限校验逻辑会直接被绕过
• 官方路由注册逻辑已经内置了路径解码、严格模式、大小写敏感等配置，无需手动处理，匹配准确率远高于自行判断

3. 请求方法未限制的安全风险 #

router.use注册的中间件默认匹配所有HTTP请求方法（GET/POST/PUT/DELETE等），如果该接口仅允许GET请求，恶意用户可通过POST等其他请求触发业务逻辑，容易引发CSRF、未授权操作等安全问题。而第二种写法明确指定了get方法，仅会匹配对应请求，更符合安全规范。

4. 可维护性缺陷 #

路由判断逻辑散落在中间件中，不符合Express的路由设计规范，后续迭代时很难快速定位所有路由定义，排查问题成本极高，也容易出现重复定义、逻辑冲突等问题。

优化建议（如果必须使用中间件形式实现） #

• 匹配到目标路由且发送响应后，直接return终止后续逻辑执行，不要调用next()
• 路径匹配改用req.path（自动解码、不含查询字符串的路径部分），可配合path-to-regexp等官方依赖实现规范的路径匹配
• 增加请求方法校验，仅允许指定方法触发业务逻辑

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