Answerdev is a question-and-answer platform written in Go. The original post is at here but the translation is what I used above since I don't read anything besides English. Using can upload pictures. When they upload a file, it's stored on the file system. When it's retrieved, a static resource server called gin will grab the resource and send it back. To prevent vulnerabilities for running JavaScript or something else on the site, the Content-Type is set based upon the file extension. This prevents many attacks, since the Content-Type changes how the browser will handle the file. The MIME standard library is used for the returning the Content-Type given a file extension. This relies upon a set of mapping files stored in a few different locations, but commonly added by other packages. If there is not an extension-to-type mapping, then this is simply ignored. Why is this bad? MIME Sniffing is the browser trying to guess the type of the response based upon the content of the page. Without a Content-Type and X-Content-Type-Options: nosniff, this functionality occurs. If we can find a file that isn't in the mapping that can be uploaded by the server, we can confuse the browser to upload HTML, leading to XSS! Oddly enough, this bug was discovered because of a difference between production and development usage of a docker container. In the production version, a minimized version of Alpine was used. So, the MIME types were not present in the container, leading to a tiff value to be used as an XSS payload. An example of this can be found at here for client side attacks. Although this is a weird use case for MIME sniffing on the server-side, it is an interesting vulnerability that is still valid in today's world.