X-Content-Type-Options

Verwendung

MIME-Sniffing ist ein Browserverhalten, bei dem der Browser den Inhalt einer Antwort untersucht und den deklarierten Content-Type anhand von Mustern überschreibt, die er im Antwort-Body findet. Ursprünglich als Komfortfunktion für fehlerhaft konfigurierte Server gedacht, öffnet MIME-Sniffing eine Sicherheitslücke: Ein Angreifer lädt eine als Bild getarnte Datei hoch, der Browser erkennt den Inhalt beim Sniffing als HTML oder JavaScript, und ein Cross-Site-Scripting-Angriff wird ausgeführt.

Der X-Content-Type-Options-Header schließt diese Lücke. Auf nosniff gesetzt, folgt der Browser strikt dem Content-Type-Header und verweigert das Laden von Ressourcen, bei denen der deklarierte Typ nicht dem erwarteten Typ entspricht. Bei Style-Zielen blockiert der Browser die Antwort, sofern der Content-Type nicht text/css lautet. Bei Skript-Zielen blockiert der Browser die Antwort, sofern der Content-Type kein gültiger JavaScript-MIME-Typ ist.

Dieser Header ist als standardmäßige Sicherheitshärtung weit verbreitet und wird zusammen mit Content-Security-Policy und X-Frame-Options für eine gestaffelte Verteidigung empfohlen.

nosniff

Der Wert nosniff ist der einzige definierte Wert. Das Setzen dieser Direktive verhindert, dass der Browser eine Antwort per MIME-Sniffing vom deklarierten Content-Type wegbewegt.

Beispiel

Ein Server liefert eine JSON-API-Antwort mit deaktiviertem MIME-Sniffing aus und stellt so sicher, dass der Browser die Antwort strikt als JSON behandelt:

Content-Type: application/json
X-Content-Type-Options: nosniff

Eine CSS-Datei, die mit dem korrekten Content-Type und Sniffing-Schutz ausgeliefert wird, sodass der Browser die Datei nicht umdeutet:

Content-Type: text/css
X-Content-Type-Options: nosniff

Fehlersuche

Von nosniff blockierte Ressourcen erzeugen Konsolenfehler, die auf eine Abweichung des MIME-Typs zwischen dem deklarierten Content-Type und dem für das Ressourcenziel erwarteten Typ verweisen.

Skript wegen abweichendem MIME-Typ blockiert. Der Browser protokolliert Refused to execute script from ’…’ because its MIME type (‘text/plain’) is not executable. Das passiert, wenn der Server eine JavaScript-Datei mit einem anderen Content-Type als einem gültigen JavaScript-MIME-Typ (text/javascript, application/javascript) sendet. Korrigieren Sie die Serverkonfiguration. Stellen Sie in nginx sicher, dass include mime.types; im http-Block steht. Prüfen Sie in Apache, ob AddType text/javascript .js in der Konfiguration oder in der .htaccess vorhanden ist.

CSS wird wegen falschem MIME-Typ bei aktivem nosniff nicht angewendet. Die Konsole zeigt Refused to apply style from ’…’ because its MIME type (‘text/html’) is not a supported stylesheet MIME type. Der Server sendet CSS-Dateien als text/html oder text/plain statt als text/css. In nginx behebt das Hinzufügen von types { text/css css; } oder das Einbinden der Standarddatei mime.types die Abweichung. Fügen Sie in Apache AddType text/css .css zur Serverkonfiguration hinzu.

Server sendet den falschen Content-Type für statische Dateien. Fehlerhaft konfigurierte Server, CDNs oder Objektspeicher (S3, GCS) liefern statische Dateien häufig als application/octet-stream oder text/plain aus. Prüfen Sie den Content-Type jeder Ressource über den DevTools-Tab Network, indem Sie die Anfrage auswählen und die Antwort-Header untersuchen. Setzen Sie bei S3 beim Upload die ContentType-Metadaten. Prüfen Sie bei über ein CDN ausgelieferten Assets, ob der Origin-Server den korrekten Typ zurückgibt, da die meisten CDNs den Content-Type des Origin-Servers unverändert durchreichen.

Blockierte Ressourcen in der DevTools-Konsole diagnostizieren. Öffnen Sie den Tab Console und filtern Sie nach MIME-bezogenen Fehlern. Jede Meldung zu einer blockierten Ressource enthält die URL, den deklarierten MIME-Typ und den erwarteten Typ. Gleichen Sie dies mit dem Tab Network ab: Wählen Sie die blockierte Anfrage aus, öffnen Sie das Panel Headers und prüfen Sie den Content-Type-Antwort-Header. Die Lösung besteht immer darin, den Content-Type auf dem Server zu korrigieren, und nicht darin, den nosniff-Header zu entfernen.

Konfiguration

Wenden Sie nosniff auf alle Antworten an. Der Mehraufwand ist vernachlässigbar, und der Schutz erstreckt sich auf Skripte, Styles und weitere Unterressourcen.

nginx:

add_header X-Content-Type-Options nosniff always;

Apache:

Header always set X-Content-Type-Options nosniff

IIS (web.config):

<code class="language-xml"><customHeaders>
  <add name="X-Content-Type-Options"
       value="nosniff" />
</customHeaders>