I'm accepting SVG files as user image uploads for a website. SVGO sometimes removes colors, breaks gradients or masks, or produces an empty image, so I'm looking for a safer approach that preserves the artwork while preventing scripts, event handlers, external references, or other injection risks. The files are stored in Cloudflare R2 rather than directly on my server, but I still want to make sure serving them cannot create security problems.
2 Answers
Inkscape’s cleanup options may produce files that happen to work, but Inkscape is not a security sanitizer. A parser-based sanitizer is a better choice for uploads. Also configure the hosting and response headers defensively: serve sanitized files with the correct image content type, avoid embedding untrusted SVG as inline HTML, and consider serving them from an isolated asset origin with a restrictive Content Security Policy. Keeping files in object storage reduces server exposure, but it does not make an unsafe SVG harmless when a browser renders it.
SVGO is primarily an optimizer, not a security sanitizer. It may remove attributes or IDs that the artwork still needs. Treat sanitizing and optimizing as separate steps: use a real SVG-aware sanitizer such as DOMPurify with its SVG profile to remove scripts, event handlers, external references, and risky elements like foreignObject. Only run SVGO afterward if you actually need optimization. If you do use it, be careful with options such as removeViewBox, cleanupIds or prefixIds, and removeUnknownsAndDefaults, since those can break scaling, gradients, masks, filters, and editor-generated SVGs.
That makes sense. I was treating storage outside the application server as if it removed the browser-side risk, so I’ll handle sanitization and serving policy separately.