SVGs seem to be getting modified when uploaded (Imgix SVG sanitization) [edited title]

Describe the issue:

SVGs seem to be getting modified and breaking some contents recently. We noticed this started happening last week, but we’re not sure when it started.

Please let us know if there’s a way to restore those assets to their original form.

(Recommended) What’s the URL of the record or model in question?

Example of one defective SVG being served:

(Optional) Do you have any sample code you can provide?

The beginning of the SVG is supposed to look like the following.

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" viewBox="0 0 4208 4208">
  <defs>
    <style>
      @font-face {
        font-family: 'GatoradeBlack';
        src: url(data:font/woff;base64,d09GRgABAA...
      }

I’ve cropped the base64 for brevity

However, this is what we’re receiving. Note how the directives in the <svg> tag were modified and the font definition got broken altogether:

<?xml version="1.0" encoding="utf-8"?>
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 4208 4208">
  <defs>
    <style>
      @font-face {
        font-family: 'GatoradeBlack';base64,d09GRgABAAAAAHIY...

There are other breaking changes being applied as well. The above is one example. Please let me know if it would be helpful if I provide the original and served files.

Hey @flavio,

That is indeed strange. Could you please post the original SVG too (or DM me or email it to us at support@datocms.com)?

It looks to me like that asset was last updated in our systems on 10/10/2023. Did someone from your org perhaps do some batch updates around that time?

@roger thank you for the quick reply. Just sent an email to support@datocms.com

Just reporting back here in case anyone else has the same issue.

The fix

Given a SVG URL on our CDN, like https://www.datocms-assets.com/119171/1716576379-svg-sanitization-demo.svg, append the ?svg-sanitize=false URL parameter to it, like https://www.datocms-assets.com/119171/1716576379-svg-sanitization-demo.svg?svg-sanitize=false

Or in GraphQL:

upload(
    filter: {filename: {matches: {pattern: "svg-sanitization-demo.svg"}}}
  ) {
    url(imgixParams: {svgSanitize: "false"})
  }

What happened

After some investigation, we discovered that this was caused by a change in our image CDN provider, who recently began sanitizing their SVGs. The workaround is to append the parameter svg-sanitize=false to the SVG’s datocms-assets.com URL.

For example, given an SVG file like this:

svg-sanitization-demo.svg

<svg xmlns="http://www.w3.org/2000/svg" width="300" height="300">
  <rect width="300" height="300" fill="blue" />
  <foreignObject class="node" x="50" y="100" width="200" height="200">
    <body xmlns="http://www.w3.org/1999/xhtml" style="background: white; font: 20pt sans-serif; text-align: center">
      <div>This is HTML inside SVG</div>
    </body>
  </foreignObject>
</svg>

It SHOULD look like this PNG screenshot:
image

Without svg-sanitize

If you access it directly from our CDN, it will be sanitized (and broken), showing only the blue square without the text inside: https://www.datocms-assets.com/119171/1716576379-svg-sanitization-demo.svg

With svg-sanitize=false

Once you add the svg-sanitize=false param, it shows the original instead:
https://www.datocms-assets.com/119171/1716576379-svg-sanitization-demo.svg?svg-sanitize=false


We apologize that this caused a disruption for our customers. This was not a change we were aware of until a customer reported it, and the Imgix svg-sanitize=false parameter was an undocumented parameter. We’ll work with our partner to better prevent incidents like this in the future. Sorry about that!

You should not need to use this parameter unless you’re having issues with your SVG files. Typically, that would only happen with SVGs that have embedded code or other data that the Imgix sanitizer removes. The sanitization happens as a default measure for security, since unsanitized SVGs can sometimes contain malicious code (including HTML, Javascript, and other things).

If your SVGs are first-party assets with basic shapes, text, etc., you shouldn’t need to worry about this. If, however, you programmatically modify your SVGs (such as targeting and modifying their nodes via code) and you’re noticing broken or different behaviors, please give this parameter a try and let us know.