XML上传校验必须在字节流层面检查前1024字节是否合法XML（如<?xml或<开头），禁用外部实体（XXE）、限制解析深度与文件大小，并使用UUID重命名、隔离存储目录，杜绝路径遍历。
XML文件上传时如何校验Content-Type
只靠前端 accept="application/xml" 或后端读取 Content-Type 字段完全不可信，攻击者能轻易伪造。真实校验必须落地到字节流层面。
- 后端接收到文件流后，先读取前几百字节（建议 1024 字节），用
Buffer.from()或类似方式提取原始二进制数据 - 检查是否以 XML 声明开头（如
<?xml）或直接以<开头，同时排除常见混淆 payload（如<?php、<script） - 避免依赖
file.type或req.headers['content-type']做唯一判断——它们在 multipart/form-data 中极易被篡改
服务端解析XML前必须设置禁止外部实体（XXE）
未禁用 DTD 解析的 XML 解析器会主动加载外部实体，导致任意文件读取、SSRF 或 DoS。这是 XML 上传最常被忽略的致命点。
- Java（JAXP）：设置
factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true) - Python（lxml）：创建
parser = etree.XMLParser(resolve_entities=False, no_network=True) - Node.js（libxmljs）：确保
parseOptions包含{noEnt: true, noDtd: true} - PHP（simplexml_load_string）：必须配合
libxml_disable_entity_loader(true)（注意 PHP 8.0+ 已废弃，改用LIBXML_NONET | LIBXML_NOENT）
限制XML结构深度和节点数量防爆破
恶意构造的超深嵌套或海量同级节点会让解析器内存暴涨甚至崩溃，属于典型的“合法格式 + 恶意体积”攻击。
- 设置最大递归深度（如 Java 的
javax.xml.XMLConstants.FEATURE_SECURE_PROCESSING） - 为解析器配置节点数上限（如 Python lxml 的
huge_tree=False+ 自定义target计数器） - 拒绝超过预设大小（如 2MB）的上传体，且该限制需在流式接收阶段就生效，不能等整个文件写完再检查
- 避免在解析后才做
len(xml_string)判断——此时攻击已完成
上传路径与存储命名必须剥离原始文件名
即使内容安全，把用户传来的 payload.xml.bak 直接存为磁盘文件，也可能绕过 Web 服务器 MIME 类型策略，触发非预期执行。
- 服务端生成全新文件名（如 UUID + 固定后缀
.xml），绝不用original_filename - 存储目录需与 Web 可访问路径隔离，或通过反向代理显式禁止对上传目录的直接 HTTP 访问
- 若必须提供下载，走后端流式响应，不暴露真实路径；响应头强制设置
Content-Disposition: attachment和Content-Type: application/xml - 警惕
..%2f、%00等路径遍历编码，解码后做规范化路径校验（如path.normalize()后比对根目录）
真正的风险不在“能不能传 XML”，而在于解析器是否被诱导执行非预期操作、存储逻辑是否信任了客户端输入、以及防御措施是否落在攻击链的正确环节上。这三个点漏掉任何一个，类型限制都形同虚设。
