X-Content-Type-Options auf Hetzner konfigurieren
Schritt-für-Schritt-Anleitung: MIME-Sniffing auf Ihrem Hetzner Cloud Server unterbinden — mit Nginx- und Apache-Konfigurationen, Verifizierung und Hetzner-spezifischen Fehlerquellen.
X-Content-Type-Options auf Hetzner
X-Content-Type-Options: nosniff ist ein einzeiliger HTTP-Header, der MIME-Sniffing im Browser unterbindet. Ohne diesen Header kann ein Browser eine hochgeladene Datei — etwa ein als Bild getarntes HTML-Dokument — als ausführbaren Code interpretieren. Das ist besonders auf Hetzner-Servern mit File-Upload-Funktionalität kritisch: Ein Angreifer lädt eine .jpg-Datei hoch, die in Wirklichkeit JavaScript enthält, und der Browser führt sie aus.
Im Wolf-Agents Web Security Check bringt dieser Header 10 von 166 Punkten. Die Konfiguration dauert unter 5 Minuten und ist auf jedem Hetzner Cloud Server, Dedicated Server oder vServer identisch — der Header wird direkt im Webserver (Nginx oder Apache) gesetzt.
Header in Nginx und Apache setzen
Auf einem Hetzner Cloud Server ist standardmäßig entweder Nginx oder Apache installiert. Der Header wird direkt in der Webserver-Konfiguration gesetzt. Das always-Keyword in Nginx ist entscheidend: Ohne dieses Keyword wird der Header bei Fehlerseiten (4xx, 5xx) nicht gesendet.
# /etc/nginx/snippets/security-headers.conf
# Oder direkt im server{}-Block
add_header X-Content-Type-Options "nosniff" always;# /etc/apache2/conf-available/security-headers.conf
<IfModule mod_headers.c>
Header always set X-Content-Type-Options "nosniff"
</IfModule>
# Aktivieren:
# sudo a2enmod headers
# sudo a2enconf security-headers
# sudo systemctl reload apache2In Nginx empfiehlt sich ein Snippet unter /etc/nginx/snippets/, das Sie mit include snippets/security-headers.conf; in jedem server-Block einbinden. So vermeiden Sie das Problem, dass ein innerer location-Block mit eigenen add_header-Direktiven alle übergeordneten Header überschreibt.
Webserver neu laden und Header verifizieren
Prüfen Sie die Konfiguration syntaktisch, laden Sie den Webserver neu und verifizieren Sie den Header per curl. Testen Sie auch eine Fehlerseite (z.B. eine nicht existierende URL), um sicherzustellen, dass das always-Keyword greift.
# Nginx-Konfiguration testen
sudo nginx -t
# Nginx neu laden
sudo systemctl reload nginx
# Apache-Konfiguration testen
sudo apachectl configtest
# Apache neu laden
sudo systemctl reload apache2
# Header verifizieren
curl -sI https://ihre-domain.de | grep -i x-content-type-options
# Erwartete Ausgabe:
# x-content-type-options: nosniffcurl -sI https://ihre-domain.de/nicht-vorhanden. Ohne always fehlt der Header bei Fehlerseiten. Häufige Fehler auf Hetzner-Servern
Fehlendes always-Keyword in Nginx
Ohne always setzt Nginx den Header nur bei erfolgreichen Responses (2xx, 3xx). Fehlerseiten, die oft sensible Informationen preisgeben, bleiben ungeschützt. Das ist der häufigste Konfigurationsfehler auf Hetzner-Servern.
mod_headers in Apache nicht aktiviert
Die Standard-Apache-Installation auf Hetzner (Ubuntu/Debian) hat mod_headers installiert, aber nicht immer aktiviert. Prüfen Sie mit apache2ctl -M | grep headers. Ohne das Modul wird die Header-Direktive ignoriert — ohne Fehlermeldung.
CDN entfernt den Header
Wenn Sie Bunny.net oder Cloudflare vor Ihrem Hetzner-Server nutzen, prüfen Sie, ob das CDN den Header durchreicht. Einige CDN-Konfigurationen entfernen Backend-Header. In Bunny.net: Pull Zone > Headers > „Override" deaktivieren. In Cloudflare ist der Header standardmäßig durchgereicht.
Compliance-Relevanz
X-Content-Type-Options ist in mehreren Sicherheitsstandards explizit gefordert. Die BSI-Richtlinie APP.3.1 (Webserver-Absicherung) verlangt, dass MIME-Sniffing unterbunden wird. Das OWASP Secure Headers Project listet den Header als Pflicht-Header. In Kombination mit einer strikten Content Security Policy bildet er die Grundlage gegen Content-Injection-Angriffe auf Hetzner-gehosteten Anwendungen.
Wie steht Ihre Domain bei X-Content-Type-Options?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 166 Prüfpunkte.