Defaults.Exposed › Behebungen › MIME-Sniffing-Schutz (X-Content-Type-Options)

So beheben Sie MIME-Sniffing-Schutz (X-Content-Type-Options)

Ein einzeiliger Header, der Browser daran hindert, zu raten, was eine Datei wirklich ist. Ohne ihn kann eine Datei, die jemand auf Ihre Seite hochlädt — oder eine Datei auf Ihren eigenen Seiten — vom Browser falsch gedeutet und als Code ausgeführt werden. Genau so verwandeln manche Angriffe einen harmlos wirkenden Upload in einen Weg, die Sitzungen Ihrer Kunden zu stehlen.

Das Wichtigste für Ihr Unternehmen: Ein fehlender Header ist ein klares, scanbares Zeichen, dass die Grundlagen nicht vorhanden sind. Für sich allein legt er selten eine Seite lahm, doch zusammen mit einem Datei-Upload-Formular oder nutzergenerierten Inhalten öffnet er einem Angreifer einen Weg, Schadcode in den Browsern Ihrer Besucher auszuführen — eingeloggte Sitzungen zu kapern, Karten- oder Login-Daten zu stehlen und Sie in ein Datenleck-Gespräch zu ziehen. Es ist eine der günstigsten Behebungen in der Sicherheit: eine Zeile, kostenlos, rund fünf Minuten.

Was Sie das kosten kann

Jede Seite, auf der Kunden oder Mitarbeiter Dateien hochladen können (Avatare, Dokumente, Support-Anhänge, Anzeigenfotos), wird zu einem möglichen Startpunkt für browserseitige Angriffe.
Ein Angreifer kann Schadcode als Bild- oder Textdatei tarnen und den Browser des Besuchers dazu bringen, ihn auszuführen — und stiehlt so dessen eingeloggte Sitzung auf Ihrer Seite.
Sicherheitsfragebögen, Cyber-Versicherungsprüfungen und Unternehmenskäufer scannen nach diesem Header; sein Fehlen liest sich als 'die machen die Grundlagen nicht' und kann einen Abschluss verzögern oder versenken.
Ältere Browser und manche Integrationen 'erschnüffeln' Inhaltstypen und können Dateien so fehlbehandeln, dass Vertrauen bricht oder Daten austreten.

Warum es wichtig ist. Ist ein Server vage darüber, was eine Datei ist, versuchen Browser zu raten ('sniffen'), welcher Inhaltstyp vorliegt. Angreifer nutzen dieses Raten aus: sie laden eine Datei hoch, die der Server als Bild kennzeichnet, gestalten ihren Inhalt aber so, dass der Browser sie für JavaScript hält — und ausführt. Der X-Content-Type-Options: nosniff-Header sagt jedem Browser, das Raten einzustellen und dem angegebenen Typ des Servers zu vertrauen, und schließt damit diese ganze Klasse von Tricks. Es ist eine bewertete Prüfung im Wert von 25 Punkten und wird bei Fehlen als mittelschwer eingestuft.

Die Kurzfassung für die Inhaberin

In jedem Webbrowser steckt eine stille Annahme: lädt er eine Datei von Ihrer Seite herunter, versucht er herauszufinden, um welche Art Datei es sich handelt. Meist vertraut er Ihrem Server. Ist Ihr Server aber vage, rät der Browser — und dieses Raten heißt MIME-Sniffing.

Das Problem: Angreifer können das Raten manipulieren. Sie können eine Datei gestalten, die Ihr Server ehrlich für ein harmloses Bild hält, die der Browser jedoch — sich selbst überlassen — für ein Stück Programmcode hält und dann ausführt, direkt im Browser Ihres Kunden, auf Ihrer Domain.

Es gibt eine einzeilige Anweisung, die das Raten abschaltet: X-Content-Type-Options: nosniff. Sie sagt jedem Browser: “rate nicht — vertraue genau dem, was mein Server dir sagt.” Das ist die ganze Behebung. Sie ist kostenlos, dauert rund fünf Minuten und zerbricht auf einer sauber gebauten Seite nichts.

Diese Prüfung sucht nach diesem Header. Fehlt er, verlieren Sie 25 Punkte und er wird als mittelschwer eingestuft — nicht, weil der Header allein eine Katastrophe wäre, sondern weil sein Fehlen ein verlässliches Zeichen ist, dass die Grundlagen nicht abgesichert wurden.

Was Sie das kosten kann

Dies sind realistische Szenarien auf Geschäftsebene — kein Worst-Case-Theater.

Der “harmlose Anhang”, der es nicht war. Sie betreiben ein Support-Portal oder einen Marktplatz, auf dem Kunden Dateien hochladen — Belege, Fotos, Dokumente. Ein Angreifer lädt eine Datei hoch, die Ihr System als Bild speichert und ausliefert. Ohne nosniff rät der Browser eines Opfers, die Datei sei in Wahrheit Skript, und führt es aus — und stiehlt still die eingeloggte Sitzung dieses Besuchers auf Ihrer Seite. Nun ist der Angreifer er: gibt Bestellungen auf, liest Nachrichten, ändert Daten. Sie erfahren es, wenn Kunden über Aktivitäten klagen, die sie nicht getätigt haben.
Der Abschluss, der an einem Sicherheitsfragebogen stockt. Das Einkaufsteam eines größeren Kunden führt vor der Unterschrift einen automatisierten Scan Ihrer Seite durch. Fehlende Sicherheits-Header zeigen sich sofort. Selbst wenn nie etwas ausgenutzt wurde, sagt der Bericht “grundlegende Web-Sicherheits-Header fehlen”, und plötzlich beantworten Sie Nachbesserungsfragen und schieben Ihren Abschlusstermin um Wochen — wegen einer Behebung, die fünf Minuten gedauert hätte.
Die Cyber-Versicherungsverlängerung, die schwerer wird. Mehr Versicherer führen vor Angebot oder Verlängerung externe Scans durch. Ein sauberes Header-Profil ist günstiger Beleg für Hygiene; ein fehlendes ist ein kleiner Makel, der, gestapelt mit anderen, Ihre Prämie hebt oder Ihre Konditionen verschlechtert.
Der Reputationsschaden, den Sie nicht leicht rückgängig machen. Lässt sich ein Sitzungs-Kaperungsvorfall auf eine von Ihrer Domain ausgelieferte Datei zurückführen, lautet die Geschichte nicht “ein obskurer Header fehlte” — sondern “[Ihr Unternehmen] hat Kundenkonten geleakt”. Das ist die Version, die Kunden erinnern, und sie kostet weit mehr, als die Behebung je würde.

Keines davon erfordert einen ausgefeilten Angreifer. Der Missbrauch von MIME-Sniffing ist gut verstanden und automatisiert, was genau der Grund ist, warum Scanner den fehlenden Header so deutlich markieren.

Was es tatsächlich ist

Erhält ein Browser eine Datei, soll der Server sie mit einem Inhaltstyp kennzeichnen (zum Beispiel image/png für ein PNG-Bild oder text/html für eine Webseite). Früher vertrauten Browser dieser Kennzeichnung nicht voll — teils, weil manche Server sie falsch setzten —, also spähten sie in die tatsächlichen Bytes der Datei und entschieden selbst. Dieses Spähen ist MIME-Sniffing.

Es war eine Bequemlichkeit, die zur Belastung wurde. Kann ein Angreifer eine Datei auf Ihre Seite bringen (über ein Upload-Formular, ein Kommentarfeld, ein importiertes Dokument) und ihren Inhalt beeinflussen, kann er etwas gestalten, das der Server harmlos kennzeichnet, der Browser aber als ausführbares Skript erschnüffelt. Der Browser führt es dann auf Ihrer Domain aus, mit dem ganzen Vertrauen, das Ihre Domain trägt.

X-Content-Type-Options: nosniff beseitigt das Rätselraten vollständig. Ist er gesetzt, wird dem Browser gesagt: verwende den vom Server angegebenen Typ und nichts anderes. Eine als Bild gekennzeichnete Datei wird als Bild behandelt, Punkt — selbst wenn ihr Inhalt wie Skript aussieht. Der Angriffsweg schließt sich.

Wie “gut” aussieht: jede Antwort Ihrer Seite — Seiten wie Assets gleichermaßen — trägt genau diesen Header:

X-Content-Type-Options: nosniff

Es gibt keinen anderen gültigen Wert und nichts zu justieren. Setzen ihn Ihr CDN und Ihr Server beide (sodass Sie nosniff, nosniff sehen), ist das in Ordnung und gilt weiterhin als bestanden.

So beheben Sie es (kostenlos, ~5 Minuten)

Geben Sie diesen Abschnitt an die Person weiter, die Ihre Website betreut — Ihre IT-Kraft, Ihre Webentwicklerin oder Ihren Hosting-Support. Die Behebung ist kostenlos und schnell; es gibt nichts zu kaufen. Was Sie verlangen, ist einfach: “Füge den Antwort-Header X-Content-Type-Options: nosniff zu jeder Seite und jedem Asset der Website hinzu.”

Hier das Detail für sie, nach gängiger Plattform.

Cloudflare (oder ein ähnliches CDN/Proxy) — oft der schnellste Ort, deckt die ganze Seite auf einmal ab:

Nutzen Sie eine Response Header Transform Rule (Rules → Transform Rules → Modify Response Header), um X-Content-Type-Options für alle eingehenden Anfragen auf nosniff zu setzen. Das wendet ihn seitenweit an, ohne den Ursprungsserver zu berühren.

Nginx — innerhalb des passenden server- (oder location-) Blocks hinzufügen:

add_header X-Content-Type-Options "nosniff" always;

Das Schlüsselwort always stellt sicher, dass er auch bei Fehlerantworten gesendet wird. Laden Sie Nginx nach dem Speichern neu.

Apache — erfordert aktiviertes mod_headers; in der Seitenkonfiguration oder .htaccess:

Header always set X-Content-Type-Options "nosniff"

IIS / Windows-Hosting — in web.config unter <system.webServer>:

<httpProtocol>
  <customHeaders>
    <add name="X-Content-Type-Options" value="nosniff" />
  </customHeaders>
</httpProtocol>

Node / Express — für jede Antwort setzen:

app.use((req, res, next) => {
  res.setHeader('X-Content-Type-Options', 'nosniff');
  next();
});

(Oder nutzen Sie das helmet-Paket, das diesen und mehrere weitere Sicherheits-Header standardmäßig setzt.)

Google-Workspace-/Microsoft-365-Seiten: diese verwalten Ihre E-Mail und Dokumente, nicht Ihr öffentliches Website-Hosting, daher wird der Header dort nicht gesetzt — er wird dort gesetzt, wo Ihre Website tatsächlich ausgeliefert wird (Ihr CDN, Webserver oder Seiten-Baukasten). Nutzen Sie einen gehosteten Baukasten (Squarespace, Wix, Shopify und ähnliche), fügen viele diesen Header automatisch für Sie hinzu; prüfen Sie das Ergebnis, statt es anzunehmen, und fragen Sie deren Support, falls er fehlt.

Nach dem Ausrollen prüfen. Führen Sie Ihren Scan erneut aus, oder lassen Sie Ihre Entwicklerin die Antwort-Header in den Browser-Entwicklertools prüfen (Tab Netzwerk → Klick auf eine beliebige Anfrage → Response Headers) und bestätigen, dass X-Content-Type-Options: nosniff vorhanden ist. Testen Sie die Seite kurz, um zu bestätigen, dass nichts Gestyltes oder Geskriptetes kaputtging — auf einer korrekt gebauten Seite wird nichts kaputtgehen.

Häufige Fehler

Ihn nur auf der Startseite setzen. Der Header muss auf jeder Antwort sein — auch auf Bildern, Skripten, Stylesheets und hochgeladenen Dateien —, denn das sind die Ressourcen, die Sniffing betrifft. Setzen Sie ihn auf Server- oder CDN-Ebene, damit er universell gilt, nicht Seite für Seite.
Ein Tippfehler im Wert. Der einzige gültige Wert ist nosniff. Alles andere (ein leerer Wert, ein Schreibfehler) lässt die Prüfung scheitern und bietet keinen Schutz. Der Scanner meldet den tatsächlich gesehenen Wert, damit Sie einen Tippfehler erkennen.
Annehmen, er ersetze eine Content Security Policy. nosniff ist eine Schicht. Er steuert nicht, welche Skripte laufen dürfen — das ist Aufgabe der CSP. Fügen Sie nosniff jetzt als schnellen Gewinn hinzu und behandeln Sie eine richtige CSP als größere Folgemaßnahme.
Das “Duplikat” entfernen. Setzen CDN und Ursprung ihn beide, sehen Sie ihn doppelt. Das ist harmlos — verschwenden Sie keine Zeit damit, eines zu entfernen.
Dafür bezahlen. Es ist eine kostenlose Konfigurationsänderung. Überwachung, Prüfungen und Portfolio-Dashboards sind zu Recht kostenpflichtig; das Hinzufügen eines einzelnen Headers nicht.

Geben Sie das Ihrer IT-Kraft

Die technische Zusammenfassung: diese Prüfung inspiziert die HTTP-Antwort-Header und besteht, wenn X-Content-Type-Options vorhanden ist und sein (case-insensitiver) Wert nosniff enthält — einschließlich des Mehrquellen-Falls nosniff, nosniff, in dem CDN und Ursprung ihn beide setzen. Fehlend oder jeder Nicht-nosniff-Wert scheitert. Es ist eine bewertete P2-Prüfung im Wert von 25 Punkten, bei Fehlen als mittelschwer eingestuft, und ordnet sich OWASP Top 10 A05 (Security Misconfiguration) zu. Die Behebung ist ein einzelner statischer Antwort-Header, über alle Antworten angewendet; es gibt keine Parameter und keine gültigen Alternativwerte. Setzen Sie ihn am Rand (CDN) für seitenweite Abdeckung, oder am Webserver mit always-Semantik, damit er auch bei Fehlerantworten ausgegeben wird, und bestätigen Sie ihn dann in den Antwort-Headern.

FAQ

Wir lassen niemanden Dateien hochladen. Brauchen wir das trotzdem?

Ja, und es lohnt sich dennoch. Der Header ist gestaffelte Verteidigung: er hindert den Browser auch daran, Skripte, Stylesheets und Datendateien von Ihrer eigenen Seite falsch zu deuten, was selbst auf Seiten ohne Upload-Formular gegen mehrere Cross-Site-Scripting-Tricks schützt. Er kostet nichts und zerbricht eine korrekt konfigurierte Seite nie, also gibt es keinen Grund, ihn auszulassen.

Zerbricht das Hinzufügen etwas auf unserer Website?

Fast nie. nosniff sorgt schlicht dafür, dass Browser den Inhaltstyp respektieren, den Ihr Server ohnehin sendet. Ärger gibt es nur, wenn Ihr Server Dateien falsch kennzeichnet — etwa ein Stylesheet oder Skript mit dem falschen Typ sendet. Geht etwas kaputt, ist das ein echter Fehler, den nosniff aufgedeckt statt verursacht hat, und er gehört ohnehin behoben. Testen Sie einmal nach dem Ausrollen.

Wie sieht 'gut' tatsächlich aus?

Ein einziger Antwort-Header auf jeder Seite und jedem Asset: X-Content-Type-Options: nosniff. Das ist die gesamte korrekte Konfiguration — es gibt keine anderen gültigen Werte und nichts zu justieren.

Unser CDN (Cloudflare oder ähnlich) und unser Server setzen ihn beide — ist das ein Problem?

Nein. Den Wert doppelt zu sehen ('nosniff, nosniff'), weil sowohl CDN als auch Ursprung ihn setzen, ist völlig in Ordnung und besteht weiterhin. Sie müssen keinen entfernen.

Kostet die Behebung Geld?

Nein. Die Behebung ist eine Zeile kostenloser Konfiguration auf Ihrem Webserver oder CDN. Wer Ihnen das Hinzufügen eines einzelnen Headers berechnet, verlangt zu viel. Bezahlenswert in diesem Bereich sind nur laufende Überwachung, eine Portfolio-Übersicht über viele Seiten oder eine formale Prüfung — nicht die Behebung selbst.

Worin unterscheidet sich das von einer Content Security Policy (CSP)?

Sie ergänzen sich. CSP steuert, welche Skripte und Ressourcen überhaupt geladen werden dürfen; nosniff hindert den Browser daran, eine geladene Datei falsch einzustufen. Sie wollen beides. nosniff ist weit einfacher und schneller hinzuzufügen und damit ein guter erster Schritt auf dem Weg zu einer vollständigen CSP.