X-Content-Type-Options für WordPress konfigurieren
Schritt-für-Schritt-Anleitung: nosniff via functions.php und .htaccess setzen, wp-content/uploads gegen PHP-Ausführung absichern.
X-Content-Type-Options auf WordPress
WordPress setzt X-Content-Type-Options: nosniff seit Version 4.7 automatisch für PHP-gerenderte Seiten. Für statische Assets und das Upload-Verzeichnis ist jedoch der Webserver (Apache oder Nginx) zuständig — dort muss der Header separat konfiguriert werden.
Besondere Aufmerksamkeit verdient wp-content/uploads: Das Verzeichnis ist öffentlich zugänglich, und ohne PHP-Execution-Block könnten hochgeladene Dateien als Scripts ausgeführt werden. Diese Anleitung zeigt beide WordPress-Methoden plus den kritischen Upload-Schutz.
functions.php: Header via send_headers
Der Hook send_headers ist der empfohlene WordPress-Weg für HTTP-Header. Er wird früh im Request-Lifecycle ausgeführt, bevor Output gesendet wird. Fügen Sie den Code in die functions.php Ihres Child-Themes ein — niemals in die des Parent-Themes, da diese bei Updates überschrieben wird.
// functions.php des Child-Themes (NICHT des Parent-Themes)
add_action( 'send_headers', function() {
// X-Content-Type-Options: MIME-Sniffing verhindern
header( 'X-Content-Type-Options: nosniff' );
// Weitere empfohlene Security-Header
header( 'X-Frame-Options: SAMEORIGIN' );
header( 'Referrer-Policy: strict-origin-when-cross-origin' );
} ); WordPress Core (seit 4.7) setzt den Header für HTML-Seiten automatisch. Dieser Code stellt sicher, dass er auch für alle anderen Antworttypen (AJAX, REST API) vorhanden ist.
.htaccess Alternative
Die .htaccess-Variante ist unabhängig von WordPress-PHP und gilt auch für statische Dateien (JS, CSS, Bilder). Sie ist die robustere Methode — wenn WordPress-PHP langsam oder nicht verfügbar ist, schützt der Header trotzdem.
# .htaccess — WordPress-Root-Verzeichnis
# Vor dem BEGIN WordPress-Block einfügen
<IfModule mod_headers.c>
Header always set X-Content-Type-Options "nosniff"
</IfModule>
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
# ... WordPress-Rewrite-Regeln ...
</IfModule>
# END WordPress BEGIN WordPress-Kommentar. WordPress überschreibt .htaccess-Inhalte zwischen den BEGIN/END-Kommentaren bei jeder Einstellung-Speicherung — Ihr Security-Header würde dann verloren gehen. Upload-Sicherheit: wp-content/uploads
Das Uploads-Verzeichnis ist öffentlich zugänglich und ohne Schutz ein direkter Angriffsvektor. Erstellen Sie eine dedizierte .htaccess im Uploads-Ordner, die PHP-Ausführung blockiert und alle Dateien als Downloads deklariert.
# wp-content/uploads/.htaccess — Upload-Verzeichnis absichern
# PHP-Ausführung blockieren (kritisch!)
<FilesMatch ".php[s0-9]?$">
Require all denied
</FilesMatch>
# Alle Uploads als Download ausliefern
<IfModule mod_headers.c>
Header always set X-Content-Type-Options "nosniff"
Header always set Content-Disposition "attachment"
</IfModule>
# Script-Typen deaktivieren
RemoveHandler .php .php7 .phtml .pl .cgi Content-Disposition: attachment bewirkt, dass Bilder im Upload-Verzeichnis als Download ausgegeben werden statt direkt im Browser dargestellt. Wenn Sie Bilder direkt im Browser zeigen möchten, entfernen Sie diese Direktive und verlassen sich auf nosniff + PHP-Block. Verifizierung
Prüfen Sie den Header für die Hauptseite, statische Assets und das Upload-Verzeichnis separat — diese können unterschiedliche Header-Quellen haben und müssen einzeln verifiziert werden.
# Header der Hauptseite prüfen
curl -sI https://ihre-wordpress-seite.de | grep -i x-content-type
# Statisches Asset prüfen (JS-Datei)
curl -sI https://ihre-wordpress-seite.de/wp-includes/js/jquery/jquery.min.js | grep -i "x-content-type|content-type"
# Upload-Verzeichnis prüfen
curl -sI https://ihre-wordpress-seite.de/wp-content/uploads/2026/01/bild.jpg | grep -i "content-disposition"
# Erwartete Ausgaben:
# x-content-type-options: nosniff
# content-disposition: attachment Wenn WordPress automatisch und Ihr Code manuell setzt, erscheint der Header möglicherweise doppelt. Das ist funktional unproblematisch, aber prüfen Sie es mit curl und entfernen Sie ggf. eine Quelle.
Wie steht Ihre Domain bei X-Content-Type-Options?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 166 Prüfpunkte.
Häufig gestellte Fragen
Setzt WordPress X-Content-Type-Options automatisch?
Seit WordPress 4.7 setzt der Core den Header X-Content-Type-Options: nosniff über die Funktion wp_headers(). Das gilt jedoch nur für HTML-Seitenantworten. Für statische Assets (JS, CSS, Bilder) ist der Webserver (Apache/Nginx) zuständig — dort muss der Header separat konfiguriert werden.
Soll ich den Header in functions.php oder .htaccess setzen?
Beide Methoden funktionieren. functions.php ist WordPress-nativ und integriert sich gut mit dem Theme, wird aber nur für PHP-gerenderte Seiten ausgeführt. .htaccess auf Apache-Ebene gilt für alle Ressourcen — auch statische Dateien. Die .htaccess-Methode ist robuster und funktioniert auch wenn WordPress-PHP ausfällt.
Warum ist die Sicherheit von wp-content/uploads so wichtig?
wp-content/uploads ist öffentlich zugänglich und enthält hochgeladene Dateien. Ohne Schutz könnte ein Angreifer eine Datei mit JavaScript-Inhalt hochladen (z.B. als gefälschtes Bild). nosniff allein reicht nicht — kombinieren Sie es mit: PHP-Ausführung im Uploads-Verzeichnis blockieren, Dateitype-Validierung beim Upload, Content-Disposition: attachment für Nicht-Bild-Dateien.
Kann ich ein Plugin für Security-Header in WordPress verwenden?
Ja. Plugins wie "Headers Security Advanced & HSTS WP" oder "WP Security Headers" setzen Security-Header über WordPress-Hooks. Der Vorteil: Keine Dateibearbeitung nötig. Der Nachteil: Plugin-Abhängigkeit und möglicherweise Konflikte mit anderen Plugins. Für produktionskritische Sites ist die direkte Konfiguration via Webserver oder functions.php zuverlässiger.
Was mache ich, wenn WordPress den Header doppelt sendet?
WordPress 4.7+ setzt den Header automatisch für HTML-Seiten. Wenn Sie ihn zusätzlich in functions.php oder .htaccess setzen, kann er doppelt erscheinen. Das ist funktional unproblematisch, aber optisch unschön. Prüfen Sie mit curl -sI, ob der Header mehrfach vorkommt, und entfernen Sie dann eine der Quellen.