How hard is it to process untrusted SVG data to strip out any potentially harmful tags or attributes (like stuff that might execute JavaScript)?
-
@simon something to check if you do this: users can right click on the image and open them in a new tab. If they do this, scripts will then run. Check that the URL doesn’t share an origin with your site. I know that blob: URLs do…
-
@simon the table at the bottom of https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe is decent
-
@jaffathecake it's the best I've seen but it still leaves me with so many questions... how good is browser support for each of those allowX things? What do browser security experts advise in terms of using them?
I'm really paranoid
-
@simon the browser support for the various allow features is in the table at the end of the page
-
@jaffathecake wow I missed that! Thank you, this helps a LOT
-
@ben_lings that's a good call - I checked and as far as I can tell the base64 URL when opened in a new page has no relationship at all to the page it was originally hosted
-
@simon @jaffathecake if you just want the SVG displayed, put them in an <img> tag. Otherwise, your favorite sanitizer library DOMPurify has great SVG support. (Iframe sandbox works really great too!!)
-
-
@jaffathecake @simon yes, totally. Dunno if Simon would want scripts in the images. If you want them, sandbox gives better controls. If you want to police the exact set of allowed elements, a sanitizer is even better.
But if all you want is to safely display them, img is really simple (don’t host the user supplied files on the same origin in either of these cases though :))
-
@freddy @jaffathecake I think I can even get away with not serving the images from a separate domain if I instead inline them as base64 SVG in the img sec attribute
(Running off a separate domain is OK for me but makes things harder for my users if I release open source code for other people to self-host)
