Automattic’s war on SVG is madness in an era of high DPR displays. It’s not difficult to fix with the Safe SVG plugin (or with code, if you prefer), however, I feel like the ability to upload SVGs should be a stock feature.
Read-only archive: Issues · ClassicPress/ClassicPress · GitHub
Author: Daniel Hendricks
Vote count: 47
Status: open
Tags:
Comments
I always have to enable SVG support almost on every single site I work on. This should be either enabled by default or given to users as an option that does not require plugins (or code snippets). An idea to make this into an option was floated in the comments. This could be a good candidate for an option to be added to the Security page. We discussed this on the security page thread.
Whatever approach we go with, this should be added.
Yeah, I’ve started using svg images and would like proper support.
Please re-read the comments for the original petition.
Allowing SVG uploads by any user provides a way for your site to get hacked. Even if you are an administrator, uploading a SVG file that someone else sends you will allow that person to hack your site.
Most people won’t understand this, so I doubt this is going to be added to ClassicPress core.
So do we scan plugin and theme files for malware before they are uploaded? Of course not, I don’t see the difference between uploading a plugin/theme file and uploading SVG file.
We trust users with zip file uploads, which can be more dangerous than an SVG upload.
SVG uploads can be enabled with a plugin or code snippet. Installing a plugin is a quick job. So why can’t we take more control over this by giving user an option to enable SVG and providing additional information or settings to help them stay safe.
Not allowing SVG uploads due to security while allowing plugin/theme uploads is basically saying to user “you can play with a chainsaw but you can’t play with a kitchen knife, we don’t trust you.”
The comments about security mention “enabled manually”. Giving user an option to enable it, is a manual way to enable it since it is off by default.
This is already happening, we can help make it more secure and better user experience.
The problem is there is in fact a massive difference, at least by what I know. Might be wrong.
Now, you would never give a guest plugin upload rights, not even an editor.
And while it is possible to fine-tune the media upload restrictions (probably not that easy thou), it is at the end the same as uploading a plugin when you start adding “dangers” to it.
Uploading Plugins, is only possible for users with a certain cap, generally, the admin, and no one would ever ask to allow this for other users.
Uploading media can even be done by a Guest, if you expose it, or an editor, or author, and is even without SVG already quite dangerous (not only SVG can hold malicious code or else metadata)
So while this is possible to do, it requires a lot more than just supporting SVG upload in core.
You will need to make cap checks inside the uploading mechanisms and screens, restrict SVG to be uploadable only by the “certain” cap (which has to be invented first), and then also hide eventual SVG (I guess) from users that should not tamper with it.
This also brings up the other question that will follow once you allow SVG upload… Why can I not edit it? ClassicPress must allow to edit it if it wants to… etc. You know what I mean I guess 
At the end we will build a Adobe Illustrator into media uploader. Because you can’t just “rotate” a SVG like you can rotate a png. Yet users will want to do it. And so forth.
It is certainly frustrating that a 2021 CMS cannot deal with SVG natively, and yet, neither can Facebook, nor Squarespace, neither any other to me known CMS or else *MS.
For example Drupal has an “extra module” (and by what I know that is a Plugin in our world) to allow that
So… we do have that already in WP (the plugin).
We just need it to be CP compatible and that for the time to come, then we wouldn’t need to deal with this in core.
I use SVG often, and I do not even see why I would want to upload them to media - they are not media, they are code in my eyes. I paste code in an editor, not in a media library.
Even if I would, I still couldn’t give that right to my writers, who would upload god knows what from the free SVG libraries/ that, would then compare to my editors uploading free plugins to my site. And I wouldn’t want that.
So if only me as admin ends up being able to upload an SVG which in fact ends up being code in an editor, I prefer just copy pasting my SVG into said editor, or if I really need it, I upload it to my server and call it by file (which I really never did with SVG, as I said, for me that is like HTML code, which I add in an editor, not uploaded as a file)
I vote to close this and declare it an important, but plugin territory feature, but can’t 
since we only have yay votes.
Everyone knows that plugins and themes pose a security risk and you shouldn’t upload them from an untrusted source.
Almost no one knows that about SVGs.
A quick Google search says SquareSpace allows it:
Exactly, that’s why we should take control of this UX and help users understand it and do it securely. They still going with a plugin to enable it anyways, and that is less secure.
Currently Squarespace only offers the option to add a .png or .jpg logo file. But there is a workaround! Squarespace doesn’t make it easy, but it is possible. Here’s how you can add an SVG logo to the Logo/Title section of your Squarespace site.
Follows a 5 steps process of very hacky things.
For me this is not what we are talking here about, which is support to upload SVG to a media manager to which potentially hundreds of users have access on your site, from guests (if exposed, which they often are) to admins.
If we are looking for a hack/workaround, then WP can do better:
The implementation/feature is not justifiable with “I can upload plugins thus I should be able to upload SVG”. It is something that you can decide for the site. Not we for hundreds of thousands of potential user who have no idea what that means.
You can add plugins to your site. Not your guests, authors or editors. Only the Admin. Only in one screen. Only if the plugin actually is following certain guides it will even allow you to activate/upload it.
Doing this for SVG in core means a lot more than just adding support for it.
It needs new caps, new upload-checks to check those special caps, new rules to check what an SVG should contain and what not. The UI for it. The logic that either calls your file or pastes the code wherever you insert it.
And it does not yet resolve the question what if a low user role, or even guest, starts to upload said SVgs because someone decided it was a good idea to allow it
We could then say “your own fault”, that is sure. But I doubt this is the logic we want to follow.
As said I support using SVG, a lot. But it is something that we can use as “code”, like HTML, not like a JPEG or PNG which is an image, and can be “inserted” and “shared”
Maybe we can add SVG support and disable it by default.
Then have documentation on how to enable and why you should not… something like define('I_NEED_TO_UPLOAD_SVG', true).
So it can be enabled when the site is under developement and then disabled, so SVG are well rendered but not uploadable.
There are libraries which can be used to validate svg files.
The evidence I have seen suggests that they don’t work. Here’s an example:
We analyzed all three XSS filters and have managed to bypass each of them, demonstrating that even the most sophisticated filtering software can never be able to fully protect against malicious markup.
– https://www.nds.ruhr-uni-bochum.de/media/hgi/veroeffentlichungen/2011/10/19/svgSecurity-ccs11.pdf
This should stay in plugin territory for the foreseeable future.
I’m in agreement with this being plugin territory for the many reasons stated here. There’s still just too much risk in allowing SVGs to be uploaded.
Maybe I’m just slow, but I don’t see the difference between giving user an option to enable SVG in core and limiting uploads to admins just like unfiltered_html and asking them to install a plugin to enable SVG support that can potentially have a vulnerability (we know how plugins are). User has choice either way, but we could make UX better and more secure than a plugin.
We trust admins with everything else related to security, and a little bitty SVG is going to end the world apparently 
Should we disable JPG or PNG image uploads since EXIF data can be used to hide malware?
Should we consider disabling plugin/theme uploads? Vulnerable plugins/themes are far greater threat than an SVG. We can’t trust users with plugins/themes if we can’t trust them with SVG.
The logic here doesn’t add up, and maybe it’s my algebra skills. I was never good with logic problems.
I go back to my previous example. We allow users to juggle chainsaws, but are afraid to let them juggle kitchen knives because they might cut themselves.
This reminds me of drinking age in the US. We can join the military at 18, smoke at 18, vote at 18. Own forearms at 18 (or younger). But got forbid we have a drink, we’re not responsible enough for that Wait till 21.
Help me understand.
The difference is: if CP adds it, CP is responsible for problems/issues; if an end-user adds it, the responsibility is their own.
By this logic, CP is responsible for everything insecure user can do in the core. But we rely on GPL to protect CP.
This is the logic that I’m not understanding.
This is correct. Note that the GPL doesn’t shield one from issues stemming from negligence.
Making this task easier makes it less secure by definition.
We also can’t make this more secure by adding it to core. The opposite is true, because plugins that handle this task have the opportunity to iterate and fix issues more quickly.
I don’t, actually. People whose sites I manage do not install their own plugins or themes.
The most secure thing to do before installing a plugin or theme is to read and understand its code, because as you said, this is also dangerous. Most people don’t do this, but at least in the case of plugins and themes, people understand that they are dangerous, so they evaluate in other ways, for example, looking for options from trusted developers with a good reputation for security.
On the other hand, the vast majority of people who would use this feature think that SVG is just another image format. What I am seeing from this discussion is that this cannot be fixed by adding any amount of warnings or messages or documentation around this feature.
I’m not going to argue for disabling plugins and themes for everyone, because it’s obviously a useful feature and the cat’s already out of the bag. However, saying that we should then enable SVG uploads for everyone is a bit like saying “it’s already broken so what’s the harm in breaking it more?”
Our homepage says “no matter how exciting a new feature is, if it’s not secure, it won’t be added.” That doesn’t say that we will disable or break already-existing things that may be dangerous, but SVG uploads are not currently supported and they are not secure. If you want to enable them on your site, then you need to take responsibility for the additional risk this adds. ClassicPress cannot take this responsibility. That means this feature needs to be explicitly sought out and enabled.
I’d be happy for us to put together some official recommendations around this issue, including which plugins to use and best practices to follow. I don’t think we can or should do more than that. My recommendation is in fact not to even use a plugin for this: in order to use SVG images, review their code, then incorporate them directly into the HTML for the posts/pages where they should appear, or directly into the theme files, as the case may be.
I’ve read through the discussion and understand the issues around adding insecure features to core, and how a plugin may adapt to security issues faster, when they arise.
Here’s what I want to clarify: what is “support in media library”? In my experience, I’m adding something to mime_types, and then the actual admin media library works as expected. I didn’t know if there was something specific to SVG that is broken after allowed for upload.
I think this is a new petition, but didn’t know if it would thrive in light of this one:
Like how it’s done in Discourse:
That is more complicated than I’m looking for, but the ability to allow admins to set “authorized extensions” might be a useful tool: “safe” by default, easy configuration.
