HTTP Security Header: zusätzlicher Schutz mit wenigen Zeilen

HTTP Security Header sind Anweisungen, die Ihr Webserver mit jeder Seite an den Browser schickt. Sie sagen ihm zum Beispiel, dass er die Seite nur über HTTPS laden darf, dass sie nicht in einem fremden Rahmen erscheinen soll oder von welchen Quellen er Skripte annehmen darf. Damit schließen Sie typische Angriffswege wie Clickjacking und das Einschleusen fremder Skripte zum großen Teil. Die meisten Header sind in wenigen Minuten gesetzt. Bei zwei davon sollten Sie aber vorsichtig vorgehen, weil sie Ihre Seite sonst lahmlegen.

Wie HTTP Security Header wirken

Jede Antwort eines Webservers besteht aus zwei Teilen: den Headern mit Angaben über die Antwort und dem eigentlichen Inhalt. Sicherheits-Header sind zusätzliche Zeilen, die der Browser liest und befolgt. Der Server schützt sich damit nicht selbst. Er bittet den Browser des Besuchers, bestimmte gefährliche Dinge nicht zu tun.

Welche HTTP Security Header Ihre Seite schon sendet, sehen Sie im Browser über die Entwicklerwerkzeuge im Bereich „Netzwerk“: Seite neu laden, die erste Anfrage anklicken, dann „Antwort-Header“. Auf der Konsole geht es mit:

curl -sI https://www.beispiel.de/

Die wichtigen HTTP Security Header im Überblick

Sechs Header decken die meisten Fälle ab. Vier davon sind unkritisch und passen auf fast jede Website. Zwei brauchen Planung.

Strict-Transport-Security (HSTS)

HSTS sagt dem Browser: Diese Domain ab jetzt nur noch über HTTPS laden, auch wenn jemand http:// eintippt oder auf einen alten Link klickt. Das verhindert, dass ein Angreifer im selben WLAN den ersten, unverschlüsselten Aufruf abfängt.

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

Der Wert max-age gibt die Dauer in Sekunden an, hier ein Jahr. Der Browser merkt sich das so lange. Setzen Sie HSTS erst, wenn Ihre Seite und alle Subdomains zuverlässig über HTTPS laufen. Beginnen Sie mit einem kurzen Wert wie max-age=300 und erhöhen Sie ihn, wenn alles funktioniert. Den Zusatz preload und die Eintragung in die Preload-Liste der Browser nehmen Sie nur, wenn Sie sich sicher sind. Ein Rückzug von dort dauert Monate. Wie Sie Ihre Seite vorher sauber umstellen, steht im Ratgeber zum Thema auf HTTPS umstellen.

Content-Security-Policy (CSP)

Die CSP legt fest, von welchen Quellen der Browser Skripte, Stylesheets, Bilder, Schriften und Rahmen laden darf. Gelingt es einem Angreifer, eigenen Code in Ihre Seite zu schleusen, etwa über ein Kommentarfeld oder ein unsicheres Plugin, blockiert der Browser ihn, weil die Quelle nicht erlaubt ist. Das ist der wirksamste dieser Header und zugleich der aufwendigste.

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

Zur besseren Lesbarkeit steht hier jede Angabe in einer eigenen Zeile. In der Konfiguration schreiben Sie alles in eine Zeile, getrennt durch Semikolons.

Dieses Beispiel erlaubt nur Inhalte von der eigenen Domain. Bindet Ihre Seite Schriften, Karten, Videos oder ein Analyse-Werkzeug von anderen Servern ein, müssen Sie diese Quellen ergänzen. Viele CMS und Themes nutzen außerdem Skripte direkt im HTML, die eine strenge CSP blockiert. Dann braucht es Ausnahmen oder eine Umstellung.

Testen Sie deshalb zuerst im Beobachtungsmodus. Unter dem Namen Content-Security-Policy-Report-Only blockiert der Browser nichts, meldet aber jeden Verstoß in der Konsole der Entwicklerwerkzeuge. Klicken Sie sich durch alle wichtigen Seiten, ergänzen Sie fehlende Quellen und schalten Sie erst dann auf die echte Regel um. Die vollständige Beschreibung aller Angaben finden Sie in der Referenz von MDN.

X-Content-Type-Options

Browser versuchen manchmal zu erraten, was eine Datei ist, auch wenn der Server etwas anderes angibt. Ein als Bild hochgeladenes Skript könnte so ausgeführt werden. Diese Zeile schaltet das Raten ab und hat praktisch keine Nebenwirkungen:

X-Content-Type-Options: nosniff

Schutz vor Clickjacking

Beim Clickjacking lädt eine fremde Seite Ihre Seite unsichtbar in einem Rahmen und bringt Besucher dazu, darauf zu klicken, etwa auf „Konto löschen“. Die moderne Lösung ist die Angabe frame-ancestors 'self' in der CSP. Für ältere Browser setzen Sie zusätzlich:

X-Frame-Options: SAMEORIGIN

Soll Ihre Seite bewusst bei einem Partner eingebettet werden, nennen Sie dessen Domain bei frame-ancestors.

Referrer-Policy

Klickt ein Besucher auf einen Link zu einer anderen Seite, verrät der Browser normalerweise, von welcher Adresse er kommt. Steht in dieser Adresse etwas Privates, etwa eine Bestellnummer oder ein Suchbegriff, geht das an fremde Server. Diese Einstellung gibt bei fremden Seiten nur die Domain weiter und ist heute auch der Standard vieler Browser:

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

Permissions-Policy

Hier legen Sie fest, welche Funktionen des Geräts Ihre Seite und eingebettete Inhalte nutzen dürfen, etwa Kamera, Mikrofon oder Standort. Braucht Ihre Seite keine davon, schalten Sie sie ab:

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

Den alten Header X-XSS-Protection finden Sie noch in vielen Anleitungen. Moderne Browser ignorieren ihn, lassen Sie ihn weg.

HTTP Security Header ohne Konsole prüfen

Ob Ihre Seite schon Sicherheitsheader schickt, sehen Sie auch ohne Befehlszeile. Öffnen Sie Ihre Website in Chrome, Firefox oder Edge, drücken Sie F12 und wechseln Sie in den Reiter „Netzwerk“. Laden Sie die Seite neu und klicken Sie auf den ersten Eintrag, also das HTML-Dokument. Unter „Antwort-Header“ stehen alle Header, die Ihr Server mitgeschickt hat. Fehlen Namen wie Strict-Transport-Security oder X-Content-Type-Options, ist hier noch etwas zu tun.

Wer keinen Zugriff auf die Serverkonfiguration hat, hat zwei einfache Wege. Bei Webspace mit Apache tragen Sie die Zeilen aus dem nächsten Abschnitt in die .htaccess-Datei ein, die Sie per FTP oder im Dateimanager des Kundenmenüs bearbeiten. Bei WordPress gibt es außerdem Sicherheits-Plugins, die die gängigen Header per Schalter setzen. Prüfen Sie danach im Netzwerk-Reiter, ob sie wirklich ankommen.

HTTP Security Header bei Apache setzen

Beim Webhosting mit Apache setzen Sie die Header in der Datei .htaccess im Hauptordner. Dafür muss das Modul mod_headers aktiv sein, was bei fast allen Hostern der Fall ist:

<IfModule mod_headers.c>
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
    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 "camera=(), microphone=(), geolocation=()"
    Header always set Content-Security-Policy-Report-Only "default-src 'self'; frame-ancestors 'self'"
</IfModule>

Das Wort always sorgt dafür, dass die Header auch bei Fehlerseiten und Weiterleitungen gesendet werden. Wie die Datei aufgebaut ist und wie Sie sie sicher bearbeiten, erklärt der Ratgeber zur htaccess-Datei.

HTTP Security Header bei Nginx setzen

Auf einem eigenen Server mit Nginx gehören die Zeilen in den server-Block der Website:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;

Eine Falle bei Nginx: Steht in einem location-Block ein eigenes add_header, etwa für den Cache von Bildern, gelten dort die Header aus dem server-Block nicht mehr. Sie müssen sie dann wiederholen oder in eine eigene Datei auslagern und mit include einbinden. Prüfen Sie nach dem Neuladen mit sudo nginx -t && sudo systemctl reload nginx auch Bilder und CSS-Dateien.

Das Minimum für jede Website

Wer nicht tiefer einsteigen will, kommt mit diesen Werten weit. Sie passen auf fast jede Seite und machen nichts kaputt:

• X-Content-Type-Options: nosniff
• X-Frame-Options: SAMEORIGIN
• Referrer-Policy: strict-origin-when-cross-origin
• Permissions-Policy: camera=(), microphone=(), geolocation=()
• Strict-Transport-Security: max-age=300 für den Anfang, nach zwei Wochen ohne Probleme max-age=31536000

Die Content-Security-Policy ist der nächste Schritt, wenn diese fünf laufen. Lassen Sie sie zuerst zwei Wochen im Beobachtungsmodus.

Content-Security-Policy und WordPress

WordPress, viele Themes und Page-Builder schreiben Skripte und Stile direkt in den HTML-Code. Eine strenge CSP mit script-src 'self' blockiert sie, und im Adminbereich funktionieren Editor und Menüs nicht mehr. Drei Wege haben sich bewährt:

• CSP nur für die öffentliche Seite: Setzen Sie die Regel so, dass sie für /wp-admin/ nicht gilt. Im Adminbereich sind nur angemeldete Nutzer unterwegs, das Risiko ist dort anders.
• Mit Ausnahmen beginnen: Eine Regel mit 'unsafe-inline' für Stile ist kein vollständiger Schutz, blockiert aber schon fremde Skriptquellen und Rahmen.
• Nonces: Eine Zufallszahl pro Aufruf, die erlaubte Skripte kennzeichnet. Das ist der sauberste Weg, braucht aber ein Plugin oder eigene Programmierung.

Beginnen Sie mit frame-ancestors, base-uri und form-action. Diese drei Angaben machen auch in WordPress fast nie Probleme und schließen schon wichtige Lücken.

WordPress, Kundenmenü und CDN

Viele Hoster bieten im Kundenmenü einen Schalter für HSTS oder ein Feld für eigene Header. Sicherheits-Plugins für WordPress können Header ebenfalls setzen. Das ist bequem, hat aber einen Nachteil: Die Header kommen dann erst, wenn PHP läuft, und fehlen bei Bildern und statischen Dateien. Besser ist die Einstellung auf Ebene des Servers. Nutzen Sie ein CDN, können Sie die Header auch dort setzen. Achten Sie darauf, dass sie nicht doppelt kommen, etwa einmal vom Server und einmal vom CDN mit anderen Werten. Weitere Maßnahmen für WordPress sammelt der Ratgeber zur WordPress-Sicherheit.

Ergebnis prüfen

Nach dem Setzen prüfen Sie die HTTP Security Header wieder mit den Entwicklerwerkzeugen oder mit curl -sI. Kostenlose Prüfdienste wie securityheaders.com bewerten Ihre Seite mit einer Note und zeigen, was fehlt. Eine gute Note ist ein Anhaltspunkt, kein Selbstzweck. Eine CSP, die alles erlaubt, bringt eine bessere Note, aber keinen Schutz.

Testen Sie danach die wichtigen Funktionen Ihrer Seite: Kontaktformular, Login, Warenkorb, eingebettete Karten und Videos, Zahlungsanbieter. Steht etwas in der Konsole der Entwicklerwerkzeuge mit dem Hinweis „Content Security Policy“, fehlt eine Quelle in Ihrer Regel.

Was HTTP Security Header nicht leisten

Die Header machen eine unsichere Anwendung nicht sicher. Eine Lücke in einem Plugin, ein schwaches Passwort oder eine veraltete PHP-Version bleiben gefährlich. Die Header sind eine zusätzliche Schicht, die Schäden begrenzt, wenn an anderer Stelle etwas schiefgeht. Die Grundlagen, auf denen sie aufbauen, beschreibt der Ratgeber zur Website-Sicherheit. Auf das Ranking in Suchmaschinen haben die Header keinen direkten Einfluss. HTTPS dagegen schon, und HSTS sorgt dafür, dass es auch wirklich genutzt wird.