- From: Nikos Andronikos via GitHub <sysbot+gh@w3.org>
- Date: Thu, 27 Oct 2016 04:09:23 +0000
- To: public-svg-issues@w3.org
nikosandronikos has just labeled an issue for https://github.com/w3c/svgwg as "agenda+": == SVG MIME Type (image/svg+xml) is misleading to developers == https://www.w3.org/TR/SVGTiny12/mimereg.html I'd like to propose the deprecation of `image/svg+xml` as the MIME type to describe SVG files. My reasoning is as follows: * SVG files can contain executable code (JavaScript). * Developers expect an `image/*` MIME type to mean data, not code. * A failure to separate data from code is a fundamental problem to software security. It turns up in: * Buffer overflows * SQL injection * Cross-site scripting * XML External Entities * Xpath injection * LDAP injection The end result is that, due to the misleading MIME type for SVG files, most developers who don't know this nuance will accidentally handle them in such a way that makes Stored XSS vulnerabilities possible. [It happened to us](https://hackerone.com/reports/148853), and it's been a known problem for years. The simplest solution is: **move to `application/svg+xml`**. This signals to developers that "this can contain executable code" and also makes naive MIME whitelists (that force a download rather than display/execute directly when a MIME type is absent) based on the `image/` prefix less vulnerable. Alternatively, we could fork into two MIME types: * `image/svg+xml` which is not allowed to contain JavaScript, and if it does, is never executed * `application/svg+xml` which is allowed to contain JavaScript (maybe reserve the `svgx` file extension for these?) See https://github.com/w3c/svgwg/issues/266
Received on Thursday, 27 October 2016 04:09:29 UTC