Simple way of opting out of SVG features that introduce security concerns

[tylersticka]

Short Version

It's a drag that SVG images can't be requested from a CDN or uploaded via web forms as seamlessly or securely as other image formats. It would be nice if there were a way (different file extension? something else?) to distinguish SVGs with dynamic behavior from those without to simplify this experience.

Long Version

One of the biggest hurdles for our customers to embrace SVGs has been security. Very frequently we hear that SVGs won't load from a CDN, or that a CMS won't accept them. It may make theoretical sense that XML documents need to be handled more like HTML documents, but when SVGs are used as an image format the distinction is not intuitive.

Don't get me wrong, I love that SVGs can include JavaScript. We use that feature on our company's homepage to make sure the animation JS is cached with the rest of the visuals, and won't be loaded if the user can't see it (or on pages with no animation at all). It's awesome.

But of the 4,848 external SVG files we've generated in the last few years (I counted!), we've only embedded JavaScript in them twice. Assuming we aren't outliers in that regard, it seems a shame that we've complicated SVG adoption for the sake of a feature used a fraction of the time.

It's possible that a solution already exists but has eluded my team. I know WordPress recently updated to disallow SVG files that don't begin with <?xml version="1.0" encoding="utf-8"?>, even when using a plugin, but it's unclear to me if that addition has value in distinguishing JS-less SVG in a meaningful way or if it was added for some other reason.

[BigBadaboom]

You may be interested in the "SVG Native" effort. It's a proposed subset of SVG intended to be used where simplicity of implementation is needed, and things like interactivity aren't.

https://w3c.github.io/svgwg/specs/svg-native/index.html

By itself, having a restricted subset of SVG won't matter if websites can't be certain that the file they are loading is the "safe" version of SVG. That problem was being discussed here:

w3c/svgwg#664

As Dirk points out in that thread. In theory loading SVG files ought to be safe now. As long as sites load them into an <img>. That's due to the web security model that modern browsers have implemented. Only very old browsers should be vulnerable to malicious SVG files.

[JeremiePat]

It's a drag that SVG images can't be requested from a CDN

This is not a CDN issue in itself but actually a known restriction of the <use> element that disallow loading cross-origin resources. This is mainly for security purpose as <use> is a doorway to malicious code if not properly sanitize before loading.

Quote from SVG2 Spec:

User agents may restrict external resource documents for security reasons. In particular, this specification does not allow cross-origin resource requests in ‘use’.

There are some discussion regarding this topic : w3c/svgwg#707
But it is hard to get consensus on how to solve that issue.

That said, from a web developer point of view I can imagine many ways to workaround that issue with some JavaScript (for example fetch resources on domain B and inline them in resources from domain A, or use a single domain in all your HTML/CSS/SVG and use a ServiceWorker to reroute request over several domains, make it pretends that they all comes from the same domain—which is tricky, I know.) That said, I agree with you that having subset of SVG that would be "image only" could be interesting.

SVG Native could bring this, however some of its restrictions are a bit hardcore for a web environment (no CSS nor <use> element for internal use for example is a bit too harsh IMO)

I know WordPress recently updated to disallow SVG files that don't begin with <?xml version="1.0" encoding="utf-8"?>, even when using a plugin, but it's unclear to me if that addition has value in distinguishing JS-less SVG in a meaningful way or if it was added for some other reason.

Having CMS requesting the XML prologue for SVG documents isn't a big surprise and there is a reason for that. If a SVG document is a proper valid XML document (which must contain an XML prologue) it is possible to use XML pipelines to sanitize the document (for example removing nasty <script> elements) without reinventing the wheel. Does WordPress actually performe some operations on SVG documents ? I don't know, but it opens the door to have plugin doing some XML magic for us ;)

[tylersticka]

Does WordPress actually performe some operations on SVG documents ? I don't know, but it opens the door to have plugin doing some XML magic for us ;)

My understanding (which may be inaccurate, I can't claim to understand all of the source to spelunk through) is that WordPress disallows all SVG documents by default. If you install a plugin to circumvent this, you then run afoul of a lower-level WordPress protection whereby certain documents aren't allowed to be uploaded unless they're able to be sanitized.