无文件上传表单全局使用enctype="multipart/form-data"是否存安全风险？

先明确给出结论：没错，这属于需要警惕的不良实践。除了你提到的早年流量翻倍问题（如今多数服务器虽已优化，但冗余流量仍会存在），这种做法还会暴露不少可被攻击者利用的安全风险，具体拆解如下：

核心安全风险与利用场景 #

1. 后端解析逻辑的潜在漏洞 #

当服务器接收到multipart/form-data格式的请求时，会按照多部分表单规则解析每个字段。如果你的后端代码原本是为普通表单（application/x-www-form-urlencoded）设计的，大概率没对多部分数据的边界、内容类型做严格校验：

• 攻击者可以伪造不存在的文件字段，哪怕业务完全不需要上传文件，若后端解析器未过滤这类字段，可能会在服务器临时目录生成无关文件；更危险的是，如果服务器错误解析这些“伪文件”内容（比如把恶意脚本伪装成图片解析），可能触发文件解析漏洞。
• 部分老旧服务器或框架在处理异常的multipart边界时，可能出现缓冲区溢出、内存泄漏问题，进而被利用执行远程代码或导致服务崩溃。

2. 轻松绕过输入验证机制 #

很多针对普通表单的输入验证逻辑，是基于application/x-www-form-urlencoded格式设计的，面对multipart/form-data时可能失效：

• 攻击者可以利用multipart的字段分隔特性，绕过前端或后端的简单校验。比如普通表单会限制输入长度，但multipart中每个字段独立分隔，部分校验逻辑未适配这种格式，会让超长或恶意内容顺利提交。
• 不少WAF（Web应用防火墙）对multipart格式的解析不如普通表单完善，攻击者可通过这种编码方式绕过WAF检测，将恶意payload传递到后端。

3. 资源消耗与DoS攻击 #

即便现在服务器处理multipart的效率有所提升，无必要的使用仍会增加资源开销：

• 解析multipart数据需要更多CPU和内存，攻击者可批量发送构造好的恶意multipart请求（比如包含大量空字段或超大无效内容），耗尽服务器资源，引发拒绝服务（DoS）。
• 哪怕不上传文件，攻击者也能在multipart字段中嵌入大量二进制数据，浪费带宽、拖慢服务响应速度。

4. 敏感信息泄露风险 #

某些场景下，multipart/form-data的解析日志会记录更多请求细节，比如字段边界、内容类型等。若服务器日志配置不当，这些额外信息可能被攻击者利用——比如通过日志摸清表单字段结构，进而构造更精准的攻击。

总结建议 #

如果业务完全没有文件上传需求，强烈建议使用默认的application/x-www-form-urlencoded编码，既能减少冗余流量，又能降低上述安全风险。若因框架限制不得不全局配置，一定要在后端添加严格校验：过滤所有非预期的multipart字段、限制请求大小、为解析过程添加异常处理等。

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