HTTP-Sicherheits-Header: Was die Header wirklich bewirken

Sicherheits-Header sind die günstigste und effektivste Schutzmaßnahme für jede Website. Jeder Header ist eine Zeile Serverkonfiguration, keiner kostet Ladezeit – und zusammen wehren sie ganze Kategorien von Cyberangriffen ab.

Dennoch sendet die Mehrheit aller Websites keinen einzigen davon.

Hier erfahren Sie, was die einzelnen Header bewirken, in welcher Reihenfolge sie implementiert werden sollten und welche zwei veralteten Header Sie aktiv entfernen sollten.

Die Basis: Drei risikofreie Header

Diese drei Header können Sie heute gefahrlos auf nahezu jeder Website aktivieren:

X-Content-Type-Options: nosniff

X-Content-Type-Options: nosniff

Ein fester Wert, kein Konfigurationsaufwand, keine Nebenwirkungen.

Ohne diesen Header versuchen Browser, den Inhaltstyp von Dateien selbst zu erraten (MIME-Sniffing). Das nutzen Angreifer aus, um manipulierte Bild-Uploads im Browser als ausführbaren JavaScript-Code ausführen zu lassen.

Es gibt keinen legitimen Grund, diesen Header wegzulassen.

X-Frame-Options

X-Frame-Options: SAMEORIGIN

Verhindert, dass Ihre Website in iFrames auf fremden Domains eingebunden wird. Das schützt vor Clickjacking-Angriffen, bei denen eine unsichtbare Kopie Ihrer Seite über betrügerische Buttons gelegt wird.

SAMEORIGIN erlaubt das Einbetten auf der eigenen Domain; DENY blockiert iFrames vollständig.

Moderne Browser unterstützen auch frame-ancestors in der Content-Security-Policy (CSP). Das parallele Senden beider Header deckt auch ältere Browser ab.

Referrer-Policy

Referrer-Policy: strict-origin-when-cross-origin

Steuert, welche URL-Informationen beim Klick auf externe Links mitgesendet werden.

Ohne diesen Header wird die vollständige URL inklusive aller URL-Parameter übertragen. Passwort-Reset-Tokens, Session-IDs oder interne Kundennummern können so unbemerkt an Drittseiten leaken.

strict-origin-when-cross-origin sendet die volle URL nur intern, bei externen HTTPS-Zielen nur die Basis-Domain und bei unverschlüsseltem HTTP überhaupt keine Daten.

Der nächste Schritt: HSTS

Strict-Transport-Security: max-age=31536000; includeSubDomains

Weist den Browser an, ausschließlich über HTTPS mit der Domain zu kommunizieren und unverschlüsseltes HTTP gar nicht erst zu versuchen.

Zwei Vorteile: Sicherheitsseitig schließt es das Zeitfenster für Downgrade-Angriffe (SSL-Stripping). Performancemäßig entfällt der HTTP-zu-HTTPS-Redirect für wiederkehrende Besucher komplett, was bei jedem Seitenaufruf einen vollen Roundtrip spart.

Vorsicht bei der Einführung: HSTS wird von Browsern strikt forciert und lässt sich nicht kurzfristig widerrufen. Haben Sie interne Subdomains, die noch kein HTTPS unterstützen, werden diese nach Aktivierung von includeSubDomains bis zum Ablauf von max-age für Besucher blockiert.

Schrittweise Einführung:

Sicherstellen, dass alle Subdomains HTTPS unterstützen.
Für wenige Tage mit max-age=300 testen.
Auf max-age=86400 (1 Tag) anheben.
Anschließend auf max-age=31536000; includeSubDomains (1 Jahr) scharfschalten.

Der stärkste Schutz: Content-Security-Policy (CSP)

Die CSP definiert verbindlich, von welchen vertrauenswürdigen Quellen Skripte, Stylesheets, Bilder, Schriftarten und Verbindungen geladen werden dürfen. Sie neutralisiert Cross-Site-Scripting (XSS) selbst bei erfolgreicher Code-Injection.

Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; frame-ancestors 'self'; base-uri 'self'; form-action 'self'

Die unsafe-inline-Falle: Viele Websites nutzen Inline-Skripte (Analytics-Tags, Pixel). Eine strikte CSP blockiert diese. Fügt man 'unsafe-inline' hinzu, lädt die Seite zwar fehlerfrei, verliert aber den Großteil ihrer Schutzwirkung. Die professionelle Lösung sind Nonces oder Hashes für legitime Skripte.

Immer zuerst im Report-Only-Modus starten:

Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report

Sammeln Sie zwei bis vier Wochen lang Berichte, tragen Sie legitime Dienste ein und aktivieren Sie die Richtlinie erst danach.

Permissions-Policy

Permissions-Policy: geolocation=(), microphone=(), camera=(), payment=()

Legt fest, auf welche Browserfunktionen Skripte auf der Seite zugreifen dürfen. Das Deaktivieren ungenutzter Schnittstellen (z. B. Kamera, Mikrofon, Standort) minimiert Risiken durch kompromittierte Drittanbieter-Skripte.

Zwei Header, die Sie entfernen sollten

X-XSS-Protection ist veraltet. Der integrierte Browser-Filter wurde in Chrome und Edge entfernt, da er eigene Schwachstellen schuf.
Server und X-Powered-By verraten Angreifern exakte Software- und Versionsnummern. Unterdrücken Sie diese Header:

Header unset X-Powered-By
Header unset Server
ServerTokens Prod

Konfiguration für Apache / LiteSpeed (.htaccess)

<IfModule mod_headers.c>
  Header always set X-Content-Type-Options "nosniff"
  Header always set X-Frame-Options "SAMEORIGIN"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header always set Permissions-Policy "geolocation=(), microphone=(), camera=()"
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains" env=HTTPS
  Header unset X-Powered-By
</IfModule>

Das Schlüsselwort always stellt sicher, dass die Header auch bei Fehlermeldungen (z. B. 404, 500) ausgeliefert werden.

Eigene Header überprüfen

Testen Sie Ihre HTTP-Header mit unserem kostenlosen Security Headers Scanner. Das Tool analysiert die Live-Header Ihres Servers und bewertet die Konfiguration nach OWASP-Standards.

Wählen Sie Ihre Sprache