Filed an issue to address this particular concern.
Thanks joepie91 for finding the folks responsible and getting the conversation started.
Currently, SVG is a security foot-cannon that allows attackers to upload a Stored XSS payload when a user views the image directly. Example.
Specifically, you can include JavaScript in an SVG document, and it will execute in all browsers if accessed directly.
This is contrary to what developers expect from a MIME type that begins with image/.
I'd like to propose:
- That the current use of SVG be moved to
application/svg+xml
- If we are to have an
image/svg+xml
MIME type, then clients MUST not allow JavaScript (or any other code execution)
Thank you for your time.
If you allow serving unsanitized user-uploaded content off a sensitive domain (e.g. the one with interesting cookies or the main application origin), you're going to have a problem nonetheless. You can mitigate some of the vectors with e.g. response headers (
Content-Type
or thenosniff
header), but not all of them can be addressed that way because of browser plugins. This has been demonstrated e.g. by Rosetta Flash or Comma Chameleon.If you choose not to sanitize (e.g. because you're scared of image processing libs memory corruption bugs), move the uploads off your origin. - you're not going to win a lot with just enforcing a
Content-type
header change.