Sanitize an uploaded SVG with a maintained library that explicitly supports SVG, allow only the features your product needs, and display the result in a context that limits scripts and external resources. Treat SVG as active web content—not just an image file. Removing <script> elements alone does not make it safe.
Why an SVG needs more than script-tag removal
SVG can contain executable behavior in more than one form. The W3C SVG 2 specification includes SVG <script> elements, event-handler attributes such as onclick, and script behavior supplied through other web-platform features in its description of script execution. A filter that removes only <script> can therefore leave other active content behind. See the SVG 2 conformance criteria.
As an Amazon Associate I earn from qualifying purchases.
References are another concern: SVG markup and CSS can point to external resources, and SVG can contain links or foreign content. Those features may cause fetching, interaction, or nested content that an image-viewing feature does not need. The SVG 2 linking specification describes secure static processing for parsed subresources; the W3C SVG Security wiki provides additional explanatory context.
Recommended Free Tools
A practical workflow for handling untrusted SVG
- Parse the upload as SVG/XML. Use a maintained parser rather than treating the file as trusted text or inserting it directly into a page. Apply upload and resource limits appropriate to your application; the cited sources do not establish universal numeric limits.
- Sanitize with an SVG-capable library. Choose a maintained sanitizer that documents SVG support. DOMPurify is one example. Start with a narrow allowlist based on the image features your product actually requires, then review the library’s settings against that policy. A general-purpose HTML sanitizer configuration is not automatically an adequate SVG policy.
- Review active features and references. Explicitly consider script elements, event-handler attributes, URL-bearing attributes, CSS imports and
url()references, links, and foreign content. Remove or reject features the use case does not require. Do not assume that a single rule—for example, removing script elements—covers these categories. - Use safe insertion and rendering. Do not send raw, untrusted SVG into an HTML DOM sink. OWASP advises against using
innerHTMLwith untrusted data and recommends sanitizing user-generated markup when markup insertion is required. See the OWASP DOM-based XSS Prevention Cheat Sheet. Choose an embedding and processing mode that disables scripting, external references, or interaction when those capabilities are unnecessary; SVG 2 distinguishes restricted processing modes from dynamic interactive processing. - Add a restrictive Content Security Policy. Configure policy directives to constrain script execution and resource loading. CSP is an additional layer, not a substitute for sanitization or safe insertion: OWASP warns that it can be misconfigured and should not be the primary XSS defense. The OWASP Content Security Policy Cheat Sheet covers policy design. CSP Level 3 is documented as a W3C Working Draft, so check the status and browser support of details you rely on.
- Maintain and verify the complete route. Keep the sanitizer dependency current, review configuration changes, and test the actual upload-to-display path in the browsers and rendering contexts your application supports. Sanitizer defaults and browser implementations can change; the sources do not establish a universally safe version, configuration, or browser matrix.
Choose the policy around the display use case
There is no universal SVG allowlist that suits every application. A simple image preview may need a narrower set of features than an editor that intentionally supports richer SVG content. Decide what users must be able to see or do, and remove capabilities outside that requirement.
Quick Recap
#1 Best Overall
| Decision | What to establish |
|---|---|
| SVG features | Which elements, attributes, styles, animation, and links the product needs; exclude unneeded active or reference-bearing features. |
| Rendering context | Whether scripts, interaction, external references, or nested content are possible, and which restrictions the chosen mode applies. |
| Insertion path | Whether sanitized output is inserted into a DOM or served and rendered as a separate resource; avoid raw untrusted markup in DOM sinks. |
| Defense in depth | How CSP constrains scripts and resource loads alongside—not instead of—sanitization. |
| Maintenance and verification | Which sanitizer version and configuration are deployed, and whether the full rendering route is retested after changes. |
What not to assume
- Removing
<script>alone does not address event attributes or other script-capable features. - A restrictive CSP does not make unsanitized SVG or unsafe DOM insertion an acceptable primary defense.
- A library’s support for SVG does not mean its default configuration matches your product’s security policy.
- No single sanitizer configuration or embedding method is established as a universal winner; the required SVG features and display context determine the appropriate policy.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
