Hi there, I have a problem on one of my projects where the webp files in the media are showing binary code instead of rendering the image. In the frontend the files don’t seem to have a problem but if you access them directly it just shows binary code.
Also my media folder seems to be vulnerable 
Index of /media (cloudfactory.com)
Could this be a server configuration issue?
My server is running on Apache with php 8.2.1 and kirby 4 on a public folder setup.
That is definitely a server configuration setup.
As regards the webp image shown as binary data, that also seems to be configuration issue, because if you look at the image in your browsers network tab, you will see that it shows up as plain text. So it seems that your mapping of extensions to mime types is not correct.
@texnixe I’ve managed to find why the webp is displaying as plain text. It seems happen once I’ve added this vulnerability fix inside .htaccess presented here:
Update .htaccess · getkirby/starterkit@db49a55 (github.com)
Idk if that’s the outcome of giving these settings or why it detects webp as unknown.
Also my media vulnerability was indeed a server configuration issue that I’ve solved.
I think I can exclude webp from that rule with the following, but I wonder if that wouldn simply make the initial vulnerability fix obsolete?
<FilesMatch "\.webp$">
Header unset Content-Type
</FilesMatch>
Edit: Adding this would not take effect in fixing the correct webp display. For now removing the vulnerability fix in the .htaccess seems to be the only option until I get more into this.
What if you remove that again and instead set the media types, e.g.
<IfModule mod_mime.c>
# Data interchange
AddType application/atom+xml atom
AddType application/json json map topojson
AddType application/ld+json jsonld
AddType application/rss+xml rss
AddType application/vnd.geo+json geojson
AddType application/xml rdf xml
# JavaScript
# Normalize to standard type.
# https://tools.ietf.org/html/rfc4329#section-7.2
AddType application/javascript js
# Manifest files
# If you are providing a web application manifest file (see
# the specification: https://w3c.github.io/manifest/), it is
# recommended that you serve it with the `application/manifest+json`
# media type.
#
# Because the web application manifest file doesn't have its
# own unique file extension, you can set its media type either
# by matching:
#
# 1) the exact location of the file (this can be done using a
# directive such as `<Location>`, but it will NOT work in
# the `.htaccess` file, so you will have to do it in the main
# server configuration file or inside of a `<VirtualHost>`
# container)
#
# e.g.:
#
# <Location "/.well-known/manifest.json">
# AddType application/manifest+json json
# </Location>
#
# 2) the filename (this can be problematic as you will need to
# ensure that you don't have any other file with the same name
# as the one you gave to your web application manifest file)
#
# e.g.:
#
# <Files "manifest.json">
# AddType application/manifest+json json
# </Files>
AddType application/x-web-app-manifest+json webapp
AddType text/cache-manifest appcache
# Media files
AddType audio/mp4 f4a f4b m4a
AddType audio/ogg oga ogg opus
AddType image/bmp bmp
AddType image/svg+xml svg svgz
AddType image/webp webp
AddType video/mp4 f4v f4p m4v mp4
AddType video/ogg ogv
AddType video/webm webm
AddType video/x-flv flv
# Serving `.ico` image files with a different media type
# prevents Internet Explorer from displaying then as images:
# https://github.com/h5bp/html5-boilerplate/commit/37b5fec090d00f38de64b591bcddcb205aadf8ee
AddType image/x-icon cur ico
# Web fonts
AddType application/font-woff woff
AddType application/font-woff2 woff2
AddType application/vnd.ms-fontobject eot
# Browsers usually ignore the font media types and simply sniff
# the bytes to figure out the font type.
# https://mimesniff.spec.whatwg.org/#matching-a-font-type-pattern
#
# However, Blink and WebKit based browsers will show a warning
# in the console if the following font types are served with any
# other media types.
AddType application/x-font-ttf ttc ttf
AddType font/opentype otf
# Other
AddType application/octet-stream safariextz
AddType application/x-bb-appworld bbaw
AddType application/x-chrome-extension crx
AddType application/x-opera-extension oex
AddType application/x-xpinstall xpi
AddType text/vcard vcard vcf
AddType text/vnd.rim.location.xloc xloc
AddType text/vtt vtt
AddType text/x-component htc
</IfModule>
Adding the MIME types suggested alongside the security headers indeed solves the issue.
Now I’m just wondering what’s the best method going forward.
Given the fact that removing the security headers introduced fixes my issue, I’m just wondering if it’s really worth keeping it giving the circumstances. 
Defining the media types with AddType is indeed the correct solution that fixes the root cause.
Such media type definitions generally belong into the global server configuration, so it looks like your hosting provider uses an outdated configuration.
If you don’t have access to the global configuration, you can use AddType in your .htaccess. Of course it’s enough to define just the types for file extensions you actually use (like AddType image/webp webp).
We recommend to. They ensure a “better broken than unsafe” setup. The reason for this being that broken setups (like the display of binary data instead of an image) are quickly discovered and fixed while unsafe setups are often only discovered when harm has been done.
If you are the only one with access to the server and the Panel, you don’t need to use the headers as the attacks that the headers protect against are not possible in that case.
No. The only goal is to disable auto-detection of MIME types. Once you explicitly define the correct MIME type with AddType, there is no need for auto-detection, so it cannot be abused.
As I wrote above, MIME types are supposed to be defined by the global server configuration. We cannot include every single piece of configuration in the .htaccess.