It'd be nice if there was a sandbox attribute you could add to inline <svg> tags, like the <iframe sandbox> attribute that'd let you opt out of all the potentially "dynamic" stuff inside of an SVG like scripts and event handlers, or even just literally sandbox the entire thing from accessing the "parent" HTML page's context/cookies/etc just like an iframe.

I'm sure it'd just open up a whole other can of worms though... not to mention having to wait for browsers to actually support it.

The real solution here is definitely CSP + basic sanitisation though.

▲

chocmake 5 hours ago | parent | next [-]

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.

	▲	rslashuser an hour ago \| parent [-]
		Exactly. It's not a good solution where you have to read a bunch of steps to do to make SVG safe, where you're worried you forgot one. Instead there should be a straightforward <svg exec="false"> or whatever that simply and comprehensively disables the unsafe features. Think of prior technologies like display postscript and .doc, where a data format ended up a with big problems from its embedded "exec" type features.

▲

simonw 5 hours ago | parent | prev | next [-]

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.

▲

bawolff 3 hours ago | parent | prev | next [-]

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.

	▲	philo23 3 hours ago \| parent [-]
		> How can you prevent it from accessing a parent doc when its not a separate document. By turning it into a document boundary when you use the sandbox attribute, kinda similar to loading an svg file inside of an <img> tag. and yeah you could get 90% of the way there with an iframe srcdoc, but I was imagining some kind of cross between an <iframe> sandboxed into its own origin, and an <img> where it still has its own intrinsic size. but it was mainly just a throw away thought, I've not really thought it through much deeper than that.

▲

somat 2 hours ago | parent | prev [-]

img src="file.svg"

does that work for you?

	▲	philo23 18 minutes ago \| parent [-]
		The main use case I was thinking of is being able to use an inline SVG, but with external resources inside of it (like say a CSS background image using url(...)) in such a way that it ends up loading that embedded content in a cross-origin anonymous way and blocking all embedded scripts. That way someone can't make requests to CSRF exploitable URLs by setting an embedded images to something like example.com/my-submission/favourite But also so that setting up a CSS transform: scale(10000) can't take over the entire viewport, it'd be constrained to an iframe-like boundary (exactly like an <img>) but still remain as an inline SVG, sort of like an <iframe srcdoc>. So scripts on the parent/host HTML document can still manipulate it like the rest of the DOM, but the inner <svg> elements are all "inert" for want of a better word. Actually I don't know off the top of my head what happens with an SVG file inside of a <img> when it references external images (either cross-domain or not.) I know scripts and animations get disabled, so I'd take a guess and say some CSS gets blocked too. Again I've not really thought terribly hard about it, or if it's actually useful at all, and I'm betting it'd be filled with even more foot-guns than there are right now. I'm just thinking out loud.