Safe SVG Handling

Introduction

SVG is an image format and a markup document. Depending on how it is delivered, it can contain links, external resource references, embedded HTML, event attributes, styles, and other behavior. A file that looks harmless in an image preview should not automatically be trusted as inline application code.

Security policy must account for the source of the file and the way the browser will embed it.

Trust and embedding decisions

Features that require review

Security review should look for script elements, event handler attributes, foreignObject, external URLs, stylesheet imports, embedded data, links, animation, filters, and references that escape the expected file boundary. The correct allowlist depends on the product; a static icon service can reject far more features than an SVG illustration editor.

File extension and MIME type are not enough. Parse the file under size and complexity limits, reject malformed input, and verify the output produced by the sanitizer.

Optimization is not sanitization

An optimizer may remove metadata, comments, groups, or unused definitions. Its purpose is structural cleanup and size reduction. Unless a tool explicitly provides and maintains a security policy for untrusted input, optimization must not be treated as a sanitizer.

Similarly, client-side processing protects file privacy by avoiding upload, but it does not make arbitrary SVG safe to paste into another website.

Safer workflow

1. 1
   Classify the source as first-party, reviewed third-party, or untrusted user content.
2. 2
   Define the SVG features the product actually needs.
3. 3
   Enforce byte, dimension, element, and complexity limits before expensive work.
4. 4
   Parse and sanitize with a maintained allowlist appropriate to the embedding context.
5. 5
   Rewrite or reject external references and active behavior.
6. 6
   Serve the result with explicit content type, download, and CSP behavior.
7. 7
   Test malicious fixtures and review the policy when browser behavior changes.

Common mistakes

Trusting the `.svg` extension

Extensions can be renamed and do not describe the parsed content. Validate format and structure.

Using a generic HTML sanitizer without SVG coverage

HTML and SVG have different elements, attributes, namespaces, and reference behavior. Confirm that the chosen library explicitly supports the required SVG policy.

Allowing every SVG feature

Broad compatibility increases attack surface. A product that only needs static icons can reject scripting, foreign content, external links, and animation.

Sanitizing once and then modifying strings

Post-sanitization concatenation can reintroduce unsafe markup. Perform transformations before the final security boundary or parse and sanitize again.

Serving uploads from the main application origin

Isolation, restrictive response headers, and a dedicated asset origin can reduce impact when the product must host user-supplied files.

Best practices

• -Keep trusted source assets in version control.
• -Use a strict allowlist for untrusted content.
• -Set input size and complexity limits.
• -Reject external resource references unless explicitly required.
• -Avoid direct innerHTML or JSX insertion of unknown SVG.
• -Keep sanitization libraries and policies updated.
• -Test the final embedding path, not only the parser.
• -Log rejected features without storing sensitive file content unnecessarily.

FAQ

Is SVG loaded through `<img>` completely safe?

Image embedding applies useful browser restrictions, but safety still depends on browser behavior, response headers, references, and what happens to the file elsewhere. Do not treat one embedding mode as a universal guarantee.

Can SVGKIT sanitize user uploads?

SVGKIT optimizes SVG structure; it is not presented as a security sanitizer for untrusted markup. Use a dedicated, maintained security boundary for uploaded content.

Should I rasterize untrusted SVG?

Rasterization can be an effective boundary for products that only need pixels, provided the rasterization service itself is isolated and maintained against malicious input.

Does Content Security Policy replace sanitization?

No. CSP is defense in depth. It can limit some resource and script behavior but should not replace validation and sanitization.

Review the OWASP File Upload Cheat Sheet and the security documentation of the sanitizer and rendering environment you actually deploy.