[wp-trac] [WordPress Trac] #24251: Reconsider SVG inclusion to get_allowed_mime_types

[WordPress Trac]

#24251: Reconsider SVG inclusion to get_allowed_mime_types
---------------------------+------------------------------
 Reporter:  JustinSainton  |       Owner:
     Type:  enhancement    |      Status:  reopened
 Priority:  normal         |   Milestone:  Awaiting Review
Component:  Upload         |     Version:
 Severity:  normal         |  Resolution:
 Keywords:  early          |     Focuses:
---------------------------+------------------------------

Comment (by mor10):

 Reading all this, I'm left with a question that has not been answered yet:

 What happens when an uploaded SVG either appears or is expected to appear
 as inline content?

 When an SVG is uploaded into WordPress and used in a post or page, it will
 be presented as a referenced item just like other image files. However, a
 theme or plugin can employ a JavaScript tool like
 SVGInjector (https://github.com/iconic/SVGInjector) to dynamically present
 the SVG as an inline element accessible through the DOM. This is after all
 what makes SVG unique: our ability to manipulate graphics using CSS and
 JavaScript.

 In a Customizer context, this is not all that problematic: The theme /
 plugin developer can ensure the inline SVG is handled properly, and put
 security measures in place to prevent unexpected behavior. However, if the
 theme / plugin dev enables dynamic rewriting of referenced SVGs as inline
 items, that can also extend to post/page content. That in turn means a
 user who uploads an SVG to use in a post or page may end up introducing
 actual code into the page. This in turn can cause serious issues both with
 presentation (repeated classes and IDs, JavaScripts targeting multiple
 elements), and with security (as live code in the DOM, the SVG becomes a
 significant security risk).

 The challenge here is that while we can, in theory, do a lot to sanitize
 the SVG as it enters the WordPress media library, we have no control over
 what happens to the SVG once it's presented on the front end because a
 theme or plugin can alter that behavior on the fly.

 Two of the major selling points of the SVG, and two of the main reasons
 many users will want to upload SVGs, are a) the ability to manipulate
 inline SVGs using CSS and JavaScript, and b) the ability to reuse symbols
 nested in an inline SVG throughout the site. While these may appear fringe
 use cases, they represent two of the main purposes for this graphics
 format and we can expect more and more users to want to hook into these
 features. And since WordPress doesn't output SVGs as inline content by
 default, users will employ JS tools to dynamically place these files
 inline.

 In my view, this is something we need to discuss and resolve before we can
 move forward. SVG is not an image file. It's a live code document that is
 meant to live inline in the DOM.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/24251#comment:68>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform