7 wichtige HTTP Security-Header für die Sicherheit deiner Website-Besucher

Sicherheit ist meistens etwas, an das gedacht wird, nachdem zum ersten Mal etwas schlimmes vorgefallen ist. Wer einmal Passwörter verloren hat, sichert sie plötzlich nur noch verschlüsselt und wer einmal seine Datenbank zerschießt, erstellt plötzlich tägliche Updates. Es muss immer erst etwas passieren, damit Zeit und Geld in Sicherheit investiert werden.

Bei Websites könnt ihr euch solche Nachlässigkeiten aber nicht mehr leisten, denn was unsicher ist, schadet im Zweifelsfall den eigenen Besuchern. Die gilt es bestmöglich zu schützen und das geschieht unter anderem mit den Security-Headers.

Diese HTTP Security-Header aktivieren, grob gesagt, Sicherheitsfunktionen im Browser, die ohne explizite Verwendung der Header nicht genutzt werden.

7 wichtige HTTP Security-Header

Die Header kommen übrigens nicht in den Head-Bereich, der sich an der Spitze einer Website befindet, sondern sind direkte Antworten des Servers, die via HTTP gegeben werden. Deshalb werden solche Header über die .htaccess Datei gesetzt.

Bitte macht vorher aber eine Kopie eurer .htaccess Datei, um diese bei bedarf wieder herstellen zu können.

X-Frame-Options

Ein altbekannter Standard ist X-Frame-Options. Hiermit wird festgelegt, ob die Website via iframe eingebunden werden kann oder nicht. Wird sie also versteckt in einer bösartigen Seite eingebettet, verhindert der Browser dies.

Für X-Frame-Options gibt es folgende Befehle.

Einbettung als iFrame komplett verbieten:

Header always set X-Frame-Options "DENY"

Einbettung nur auf sich selbst erlauben:

Header always set X-Frame-Options "SAMEORIGIN"

Einbettung auf bestimmten Quellen erlauben:

X-Frame-Options: ALLOW-FROM https://xyz.de

Referrer-Policy

Mit diesem Security-Header lässt sich der Referrer deaktivieren, der normalerweise mitgesendet wird. Soll heißen: Besucht ihr xyz.de und klickt dort auf einen Link zu abc.de, würde abc.de den Referrer sehen, also nachvollziehen können, dass ihr gerade von xyz.de gekommen seid.

In Zeiten von DSGVO und Datenschutz, möchte eigentlich niemand mehr, dass solche Daten übertragen werden. Unterbinden könnt ihr dies mit folgendem Befehl:

Header set Referrer-Policy "no-referrer"

Es kann allerdings sein, dass einige Partnerprogramme den Referrer benötigen, um eure Conversions korrekt nachzuvollziehen. Auch wenn die meisten heutzutage andere Techniken nutzen, solltet ihr dies also überprüfen.

X-Content-Type-Options

Es kann vorkommen, dass eine Datei auf dem Server liegt, deren Endung und Typ unklar sind. Ist dem so, prüft der Browser den sogenannten Content-Type Header. Fehlt dieser, rät der Browser schlichtweg den Typ der Datei, was gefährlich sein kann, denn theoretisch könnten Angreifer Bilddateien ablegen, die eigentlich HTML-Dateien sind und so weiter.

Der Befehl unten verhindert, dass der Browser, sollte der Dateityp nicht klar sein, den Typ automatisch wählt:

Header set X-Content-Type-Options nosniff

X-XSS-Protection

Dieser Secutiy-Header verhindert Reflective Cross-Site-Scripting. Dabei wird Code via URL oder POST-Parameter eingeschleust, der dann an den Benutzer reflektiert wird.

Das lässt sich aber einfach verhindern und zwar mit folgendem Befehl:

Header set X-XSS-Protection "1; mode=block"

Strict-Transport-Security

Der HTTP Strict-Transport-Security Header sorgt dafür, dass es keine Anfragen mehr ohne HTTPS gibt. Im Grunde wird dem Browser also gesagt, dass die Website HTTPS voraussetzt. Versucht also nun jemand HTTP zu nutzen oder Angriffe mit entsprechenden Links zu realisieren, wird vom Browser automatisch auf die HTTPS-Version der Website umgeleitet, die solche Angriffe unmöglich macht.

Der HTTP Strict-Transport-Security Header funktioniert ähnlich wie eine Cache-Funktion, denn er bestimmt, dass eine Seite für mehrere Monate (Zeitraum frei wählbar), ausschließlich via HTTPS erreicht werden kann. Und zwar nur noch via HTTPS. Prüft also vorher, ob alles ordnungsgemäß funktioniert.

Header set Strict-Transport-Security "max-age=31557600" env=HTTPS

Content-Security-Policy

Der Content-Security-Policy Header ist ein wenig kompliziert. Über ihn lässt sich festlegen, welche Quellen, für welche Dateitypen in Frage kommen. So kann festgelegt werden, dass die CSS-Dateien ausschließlich von der eigenen Domain stammen dürfen, externe CSS-Dateien also ignoriert werden. Gleiches gilt für Javascript oder Frames.

Im Grunde wie eine Art Firewall, die alles blockt, was nicht ausdrücklich erlaubt wurde. Probleme gibt es allerdings mit Inline-Code, der oft Basis für Cross-Site-Scripting Attacken ist, weshalb es ziemlich schwierig werden kann, den Content-Security-Policy Header richtig zu konfigurieren.

Wer möchte, kann sie hier in das Thema einlesen und dann seinen eigenen Header zusammenbauen. Eine Universallösung gibt es hier leider nicht, da es auf die jeweilige Website ankommt.

Feature-Policy

Die Feature-Policy ist da schon wieder einfacher. Diese ermöglicht es, Funktionen des Browsers komplett zu deaktivieren, die in irgendeiner Art und Weise relevant für den Datenschutz oder die Sicherheit sind.

Dazu gehören die Webcam, das Mikrofon, die Ortungsfunktion oder auch Payment-APIs, wie Apple Pay. Mit dem Feature-Policy Header kann so etwas komplett deaktiviert werden, sodass gar kein Zugriff mehr darauf besteht.

Damit schützt ihr eure Nutzer vor eventuellen Angriffen auf persönliche Daten, da, selbst wenn ein Angriff stattfindet oder Schadcode integriert werden kann, kein Zugriff auf diese heiklen Funktionen besteht.

Auch das ist aber etwas individueller, weshalb sich Interessierte ein bisschen einlesen müssen. Das könnt ihr unter anderem hier, wo der Feature-Policy Header recht gut beschrieben und erklärt wird.

So verwendet ihr die HTTP Security-Header

Welche Header es gibt und wofür diese verantwortlich sind, hat der Artikel euch nun aufgezeigt. Die Einträge könnt ihr, wenn ihr einen Apache HTTP Server nutzt (Standard bei den meisten Hostern) einfach in eure .htaccess kopieren. Fortan sind sie aktiviert und werden entsprechend berücksichtigt.

Ob die verschiedenen HTTP Security-Header korrekt funktionieren, könnt ihr mit diesem Tool genauer testen. Alles was grün ist, wurde korrekt integriert, alles was rot oder gelb ist, erfordert unter Umständen eine weitere Kontrolle.

Sicherheit und Google-Ranking

Welche HTTP Security-Header ihr einsetzt, bleibt am Ende euch überlassen. Persönlich habe ich in letzter Zeit viel mit den Funktionen herumgespielt, auch um herauszufinden, ob Google Sicherheit berücksichtigt oder in irgendeiner Art und Weise belohnt. Das ist mir zwar nicht aufgefallen, prinzipiell sind sichere Seiten aber wichtig und Schadcode wäre definitiv ein Problem, weshalb die HTTP Security-Header vor allem als Prävention dienen.

Die einzigen beiden Header, die meiner Ansicht nach optional und nicht immer so einfach nutzbar erscheinen, sind der Content-Security-Policy und Feature-Policy Header. Hier kann viel schiefgehen, da schon Inline-Code oft als unsicher eingestuft wird, bei vielen aber relativ normal geworden ist. Damit wird das Konfigurieren zur Fummelei und ein Fehler oder ein neues Plugin, erfordert oft schon wieder eine neue Einstellung.

Für ein wenig Sicherheit zu sorgen, gehört für Webmaster inzwischen mit dazu und so hoffe ich, dass ich dem ein oder anderem Neuling klarmachen konnte, warum die HTTP Security-Header eine wichtige Sache sind.