The woes of sanitizing SVGs (opens in new tab)

And any additional CSP directives can only narrow what's allowed. Also works with headers plus <meta> - <meta>s can restrict the CSP even more than what the headers specified, but they can't widen it.

An idea I’ve been kicking around (which isn’t quite applicable to this use case, I think) is to aggressively restrict the Sec-Fetch- headers on user content. If a server is willing to serve up an untrustworthy SVG, it could refuse to serve it at all unless Sec-Fetch-Dest has the correct value, and ‘document’ and ‘iframe’ would not be correct values. This would make it more difficult to fool a user or their browser by, for example, linking to an SVG file, or using a less-secure mechanism like embed to load it.

This should be in addition to heavily restricting CSP on user content. (Hmm, surely all images should be served with the CSP header set.)

Nice, favorited... thinking this could be useful for an email reader to support css, but not scripts.

I did not know about `srcdoc`, but it looks like that's still vulnerable to injection by using a double quote and </iframe> to escape the sandbox. If this is constructed in a hygienic way using DOM manipulation, it seems like it could work, but it definitely seems possible to screw up.

This is what happens when there isn't an adult in the room to reign things in, you get project overreach. SVGs should never have supported scripting. You want scripting in SVGs, fine, make it a different file format.

I can't imagine the cumulative number of man hours wasted on this problem when the vast majority of users were just looking for a way to make their logos look sharp.

I think you're right but the lack of industry standard for this kind of thing kills it. People want to be able to take the output of whatever tool they use that exports SVG and put it in a browser. Which isn't an unfair request. But you wouldn't have a guarantee it wouldn't filter out the tool using some obscure SVG functionality.

I'd love to see an agreed standard like OpenGL vs OpenGL ES for SVG. SVG-ES. Everyone agrees on the static, non-scripted elements that should work.

> My first thought is "support a tiny subset of svg that probably still covers 90% of real-world use cases".

It sounds like the linked post was about someone using a blacklist instead of a whitelist. It doesnt matter how tiny your subset is if you allow through stuff you don't recognize.

For the most part svg is safe. The dangerous parts are pretty obvious - script tag, image tag, feImage tag, attributes starting with on, embedding html in <foreignObject>, DTD tricks, namespace tricks, CSS that loads external stuff (keep in mind also presentational attributes. Its not just style attribute/tag).

The rest of it is pretty safe.

Seems like someone already implemented your idea. https://tinyvg.tech/

There's the SVG Tiny profile that some implementations use, like BIMI/VMCs.

Fwiw I just thought the same, parse (don’t validate) the bits you like and recreate / reject the input.

I wonder if it would be best if this was at the browser level as some sort of new format. Otherwise surely it would be really slow/cumbersome to deal with these in ‘user space’

I would say that a proper sanitizer should remove any attribute that has /https?:/ in it. Maybe it should allow access to a subtree of a blessed domain you control, where stuff like textures is stored.

It always seems like any animated svg loses all of the animation after sanitizing

SVG Tiny PS (Portable Secure) is an attempt at this - https://www.ietf.org/archive/id/draft-svg-tiny-ps-abrotman-0...

Though I think it's still a draft, it does appear to be a requirement for BIMI - https://en.wikipedia.org/wiki/Brand_Indicators_for_Message_I...

Yeah, I think that's the real answer.

Look at what Microsoft did with Excel--the dangerous stuff is behind a switch.

Thus, solution:

Add two bits to the tag.

SVG1 does not execute any sort of script.

SVG2 does not follow links.

SVG3 is actually SVG1 + SVG2 as these are bit flags, not numbers.

Additional bits are reserved for future use if any other issues are found.

The only real safety is in the engine, not by any sanitizer.

You'd lose a lot of useful features, like SMIL animation.

So if you are building something where you control every SVG ever produced and rendered then this is totally reasonable.

If you ever need to interface with other tools that generate SVG you now need to have a way of essentially transpiling SVG from the wild into your tamed SVGs. Oftentimes this is done by hand, by a software developer and designer (sometimes the same person).

And this is for basic functionality that your designers expect and have trivial controls for in their vector editors, like "add a drop shadow."

The article goes into some issues with sanitization itself, and except for <script> these are a bunch of reasonable things that someone might expect to work or not have issues with. Sandboxing rendering isn't an unreasonable approach if you're not writing the parser and renderer yourself.

That post mentions that I disclosed this to Scratch in February 2024. The POC in that post is functionally identical to a POC I provided them back then and in various subsequent communications.

Good reference, along with the article. I built a SVG sanitizer in Go and will look to these to make it more strict.

Most of the aspects the author was critiquing are actually just regular CSS features, they simply don't want any external requests. Effectively they want inlined SVGs to be treated like how the browsers treat IMG-embedded SVGs (no scripting or external requests loaded).

Sanitization-wise it's already possible to strip scripting from SVGs and anything else you want, it's just that a library like DOMPurify to avoid ballooning in size doesn't include say a preset to handle the extra parsing necessary to make them behave like browsers treat IMG embeds, so it's up to devs to add their own.

But yeah, a world where a simple attribute to achieve the same effect as an IMG embed but for inlined SVGs would be nice.

Thankfully if you have CSP you don't need even basic sanitization, which is useful because most of the problems in this article are demonstrations of how simple sanitization isn't simple at all.

I dont see how that could work, as an <svg> tag in html is not a document boundry. How can you prevent it from accessing a parent doc when its not a separate document.

There is iframe srcdoc if you want to do this.

img src="file.svg"

does that work for you?

We need a secondary official SSVG (Secure SVG) spec so the changes can be guaranteed by browsers and other implementors.

This would allow an update to the xmlns to

    <svg xmlns="http://www.w3.org/2000/ssvg">

Which would allow the image to force SSVG mode and disable all non-approved features, but you could also update the image tag so the client could force security on potentially insecure SVGs

    <img type="ssvg" src="/insecure.svg">

They totally could sanitize it, just like they did with the gadget proxy, they just choose not to fix this ancient request.

It's like my ticket to add data url support to sheets. It just gets punted year after year.

Workaround: https://simonsocolow.com/tech/uploading-svg-to-google-slides...

They want to run getBBox [1] which requires the SVG to be in the DOM somewhere - otherwise it throws an error. They need to do this because SVGs tend to have very inaccurate viewboxes, especially when working with SVGs made in old versions of Scratch. getBBox is the easiest way to get a more accurate understanding of how big the stuff in the SVG is.

[1]: https://developer.mozilla.org/en-US/docs/Web/API/SVGGraphics...

Wrapping text is a bit tricky because of differences in text wrapping algorithms. Though I suppose an "easy" fix would be to be able to specify a very specific algorithm (to ensure equal representation across systems), or allowing custom (possibly better-quality) wrapping.

But for the most part, I 100% agree, and I've been considering making a format for my own use-cases. I think the biggest issue is in agreeing as to what subset is necessary; plus, of course, getting any level of adoption (though the latter isn't a factor for my own use ... except in the sense that there are no tools to help).

For example, do we need animations? Gradients? If so on the latter, what kind?

Some of the suggestions are kind-of exactly that. But they specify not a change to the default behavior, but a new behavior based on the presence of a new attribute.

You could change the default behavior to the “safer” behavior. And then add some sort of “danger mode” attribute. But… devs are usually hesitant to do something that would break legitimate code, such as changing the default behavior would do.

Browsers already treat the same SVG differently depending on how you embed it. <img> strips scripts and external resource loads. <object> and inline don't. People test with img tags, looks fine, then someone switches the embed method and everything opens up.

A markup language can be an image format. The "G" is for "Graphics" after all.

Since 2019, Scratch is written to run in a standard web browser, replacing the older Flash runtime/editor. The desktop app uses Electron.

This was the example from their test suite. I didn't want to clone and build a 2019 copy of Scratch to test it end-to-end since the specifics weren't super important anyway.

SVG in an <img> tag can't execute scripts.