X-Content-Type-Options: nosniff richtig setzen

Fehlt der X-Content-Type-Options-Header mit dem Wert nosniff, kann der Browser bei mancher Antwort selbst entscheiden, wie er eine Datei interpretiert — unabhängig davon, was der Server eigentlich deklariert hat. EverAudit meldet das als Sicherheitsbefund in der Kategorie „Security-Header".

Was ist das Problem?#

Sendet ein Server eine Datei mit fehlendem, unklarem oder falsch gesetztem Content-Type, versuchen manche Browser über sogenanntes MIME-Sniffing selbst zu erraten, um welchen Dateityp es sich handelt — anhand der ersten Bytes des Inhalts. Ohne den nosniff-Header ist dieses Verhalten aktiv erlaubt.

Der Header sieht so aus:

X-Content-Type-Options: nosniff

Er hat nur diesen einen möglichen Wert und weist den Browser an, ausschließlich dem vom Server gesendeten Content-Type zu vertrauen — unabhängig davon, wonach der eigentliche Dateiinhalt aussieht.

Warum prüft EverAudit das?#

EverAudit prüft bei jeder gecrawlten Seite die HTTP-Response-Header auf das Vorhandensein von X-Content-Type-Options: nosniff. Der Header wird üblicherweise zentral am Webserver oder CDN gesetzt und betrifft dann automatisch alle ausgelieferten Ressourcen — sein Fehlen weist EverAudit deshalb als Prio-1-Befund aus, da es sich um eine grundlegende, breit wirkende Schutzmaßnahme handelt.

Welche Auswirkung hat das?#

Ohne nosniff kann eine Datei, die eigentlich harmlos gedacht ist — etwa ein von Nutzern hochgeladenes Bild oder ein Text-Upload — vom Browser fälschlich als HTML oder ausführbares Skript interpretiert werden, wenn ihr Inhalt entsprechende Merkmale enthält. Das öffnet einen Weg für Cross-Site-Scripting, selbst wenn der Server die Datei korrekt als unkritisch deklariert hat.

Besonders relevant ist das bei Websites, die Datei-Uploads von Nutzern zulassen — etwa Profilbilder, Dokumentenanhänge oder Kommentar-Anhänge. Ohne nosniff reicht eine geschickt präparierte Datei aus, um im schlimmsten Fall Schadcode im Kontext der Website auszuführen und damit an Session-Daten oder Zugangsinformationen von Besuchern zu gelangen. Für den Seitenbetreiber bedeutet das ein unnötiges Restrisiko an einer Stelle, die sich mit einer einzigen Konfigurationszeile schließen lässt.

Wie beheben Sie das?#

Setzen Sie den Header serverseitig, unabhängig vom eingesetzten CMS oder Framework:

• Nginx: add_header X-Content-Type-Options "nosniff" always;
• Apache: Header always set X-Content-Type-Options "nosniff"
• Node/Express: res.setHeader('X-Content-Type-Options', 'nosniff') oder per helmet-Middleware (dort standardmäßig aktiv).
• CDN/Reverse-Proxy: Die meisten CDN-Anbieter erlauben das Setzen zusätzlicher Response-Header über eine zentrale Regel, ohne dass die Anwendung selbst geändert werden muss.

Prüfen Sie zusätzlich, dass Ihr Server für alle ausgelieferten Dateien — insbesondere von Nutzern hochgeladene Inhalte — einen korrekten, spezifischen Content-Type-Header sendet (z. B. image/png statt application/octet-stream). nosniff wirkt nur zuverlässig zusammen mit einem sauber gesetzten Content-Type; beide Maßnahmen ergänzen sich.

Fazit#

X-Content-Type-Options: nosniff ist einer der einfachsten Security-Header überhaupt — ein einziger, immer gleicher Wert, gesetzt an einer zentralen Stelle. Er schließt eine Lücke, die vor allem bei Datei-Uploads relevant wird, und sollte deshalb auf jeder Website Standard sein.