SVGKit
Back to blog

SVG security checklist for untrusted files

SVG is XML with rendering and scripting capabilities, not a passive bitmap. Treat an unknown SVG as active content until it has been inspected and sanitized.

Inspect active content

Look for script elements, event-handler attributes, foreignObject, animation, links, and style rules that can trigger external behavior. Removing one script tag is not enough if other active mechanisms remain.

untrusted-icon.svg <script> steal credentials</script> <rect onclick="…" /> <use href="https://cdn…"/> style { background: url(…) } <foreignObject> HTML inside visible geometry — usually safe One file, several smuggling routes. Active content Executes in HTML contexts. Strip on import; never embed untrusted SVG inline. External references Pull resources (and leak viewer IPs) at render time. Prefer self-contained files. Before you trust a file Sanitize with known-safe rules, preview sandboxed, and keep scripts out.
The smuggling routes an SVG file can carry — and what to check before trusting one.
An untrusted SVG file outline with script, onclick, external use href, CSS url, and foreignObject lines highlighted as risks, annotated with active content, external reference, and trust advice.

Review external references

Images, fonts, filters, CSS, and links can reference remote URLs or local fragments. Decide whether every reference is necessary, then remove or inline resources that should not contact another origin.

Choose a safe embedding method

An SVG loaded as an image has different capabilities from inline SVG or an object element. Use the least-privileged embedding method that supports the required appearance and interaction.

Sanitize and verify

Use a maintained sanitizer or a clearly defined allowlist for production uploads. Render the cleaned result in an isolated environment, compare its appearance, and apply a restrictive Content Security Policy where possible.