前端上传文件怎么防 SVG 风险：扩展名、MIME 与内容校验的边界

允许用户上传 SVG，真正棘手的地方不在文件选择框，而在“上传后由谁解析、以什么类型返回、能不能和业务页面同源打开”。文件名、浏览器传来的类型和内容本身都可能互相矛盾，前端提示只能减少误选，不能单独承担安全判断。

如果业务并不需要 SVG，最稳妥的方案是只接收 JPG、PNG 等必要格式；如果必须支持 SVG，就把扩展名、声明类型、实际内容、存储位置和响应头当成一条完整链路来校验。

先把 SVG 上传链路拆开看

一次上传至少经过四个边界：浏览器选择文件、HTTP 请求携带文件、服务端保存文件、浏览器再次请求文件。每个边界看到的字段都不同。比如 accept="image/svg+xml" 会影响文件选择器的筛选，但用户仍可以改名、构造请求，或者直接绕过页面发请求。

先定义业务资产：如果上传内容只用于头像或缩略图，SVG 的动态能力通常没有必要；如果是图标编辑器或插画协作，才有理由保留 SVG。这个决定会直接影响后面是否允许原始 SVG 回到浏览器。

扩展名和 MIME 为什么都不能单独拍板

扩展名适合做第一道快速筛选，但不能相信原始文件名。服务端应先解码名称，取最后一个扩展名，再与业务允许列表比较；保存时不要沿用用户提供的名称，而是生成自己的存储名。

请求里的 Content-Type 也只是上传方声明，容易被伪造。它可以帮助拦截明显的误选，却不能证明内容就是安全的 SVG。实际类型检测、文件内容解析和业务规则需要一起参与判断。

const allowed = new Set(["image/png", "image/jpeg"]);
const declaredType = file.type;

if (!allowed.has(declaredType)) {
  throw new Error("unsupported upload type");
}

// 这里只做浏览器体验层提示；可信判断仍由服务端完成。
if (file.size > 2 * 1024 * 1024) {
  showError("文件不能超过 2 MB");
}

如果业务可以改成 PNG，这里就不要为了“格式看起来更灵活”而放开 SVG。允许列表越窄，后续解析器、投放策略和测试矩阵越容易控制。

必须支持 SVG 时，风险要分三档处理

只在编辑区短暂使用

这种场景可以把文件当作待处理输入，先放到非公开目录，经过解析、净化或转换后再进入业务对象。编辑预览也要限制加载方式，避免把未处理的原始文件直接嵌入同源页面。

需要公开展示静态图形

优先将 SVG 转换成 PNG 或 WebP，并以新文件名保存结果。转换不是万能许可，仍要限制尺寸、处理时间和资源消耗；转换失败时应拒绝文件，不要把原始内容作为兜底展示。

必须下载原始 SVG

把原始文件和业务站点隔离，使用独立资源域名或受控下载接口。返回时设置准确的媒体类型与下载策略，避免让浏览器把用户文件当作业务页面的一部分解释。是否允许内嵌，应由业务明确决定，而不是由文件扩展名自动决定。

一套能落地的校验顺序

我更建议把判断写成可审计的流水线，而不是散落在上传控制器里的几个正则：

1. 确认用户已经登录，并检查当前账号是否有上传权限。
2. 解码文件名，限制长度和字符集，只取最后扩展名。
3. 限制大小、像素尺寸和处理时长，拒绝超出业务需要的文件。
4. 用允许列表比较扩展名、声明类型和检测类型；三者矛盾时拒绝或转人工处理。
5. 对 SVG 做内容解析和净化，或转换成位图；不要只删除几个字符串就宣布安全。
6. 使用随机存储名，放在非 Web 根目录或隔离资源域名。
7. 记录上传者、检测结论、处理结果、文件标识和失败原因，方便追查。

审计记录不要保存完整的原始文件名作为下载地址，也不要把用户可控内容拼进日志模板。文件标识、检测阶段和结果比一段无法检索的自由文本更有用。

浏览器返回时，响应头和投放位置同样重要

上传成功不等于可以直接用原始 URL 打开。投放层至少要核对实际响应的媒体类型、是否允许内嵌、资源域名是否与业务主站隔离，以及缓存策略是否会让错误文件长期留存。不要让用户提交的名称决定响应头，也不要让页面中的预览组件默认使用最高权限的嵌入方式。

如果前端需要展示错误信息，错误状态也应清楚区分：格式不允许、检测失败、净化失败、权限不足和处理超时。这样既方便用户修正，也能让运营或安全人员从日志里判断是哪一层出了问题。

上线前用几组反例做回归

测试不要只上传一个正常图标。至少准备改后缀名的文件、声明类型和实际内容不一致的文件、超大文件、包含外部引用的 SVG、解析失败的 SVG，以及净化后仍无法通过业务规则的文件。每组都要检查 HTTP 状态、保存结果、日志事件和浏览器展示行为。

验收标准可以写得很具体：不允许的类型不会进入公开存储；处理失败不会回退到原文件；下载地址不暴露原始文件名；响应媒体类型和实际内容一致；同一资源在独立域名访问时不会获得业务主站的会话能力。

常见问题与边界判断

前端把 accept 写成 image/svg+xml 就够了吗？

不够。它主要改善文件选择体验，真正的类型和内容判断必须在服务端完成。

把 SVG 改名成 .png 能解决问题吗？

不能。改名不会改变内容，服务端仍应根据实际内容处理；需要位图时应经过可靠转换并重新生成文件。

所有 SVG 都必须禁止吗？

不必一概而论，但必须由业务用途决定。头像、封面等简单图片通常可以收窄为位图；编辑器场景则需要更严格的净化、隔离和回归测试。

最后的检查清单

上线前逐项确认：是否只开放必要格式，是否同时限制大小和处理资源，是否不信任文件名与请求类型，是否处理或转换了 SVG，是否使用随机文件名和隔离投放，是否返回正确媒体类型，是否记录检测结果，是否覆盖了反例回归。只要其中一项没有明确负责人，上传功能就还没有真正闭环。