Die 5 HTTP-Security-Header, die oft fehlen

Wenn Ihr Browser eine Website lädt, sendet der Server nicht nur das HTML zurück. Er sendet auch eine Reihe von HTTP-Response-Headern: kleine Anweisungen, die dem Browser mitteilen, wie er sich verhalten soll. Die meisten davon sind technische Infrastruktur, die niemand wahrnimmt. Fünf davon sind jedoch Sicherheitskontrollen. Fehlen sie oder sind sie falsch konfiguriert, hat der Browser keine Möglichkeit, Ihre Besucher vor einer ganzen Klasse von Angriffen zu schützen.

Noroshi prüft diese Header bei jeder Website. In unserer Auswertung europäischer KMU-Websites scheitern mehr als 80% an mindestens drei dieser fünf Header. Die gute Nachricht: Die Behebung kostet nichts und dauert weniger als einen Nachmittag.

Was Security-Header tatsächlich bewirken

Security-Header sind die Art, wie der Server dem Browser Grundregeln vorgibt. Ohne sie fällt der Browser auf seine freizügigsten Standardeinstellungen zurück: Er führt jedes Skript aus, zeigt die Seite innerhalb des Frames einer anderen Seite an, sendet Cookies über HTTP und teilt Ihren Servertyp mit jedem, der fragt. Alle diese Standards wurden schon unzählige Male ausgenutzt.

Die fünf Header, auf die es ankommt:

1. Content-Security-Policy (CSP)

CSP teilt dem Browser mit, welche Skripte, Stylesheets, Schriften und andere Ressourcen geladen werden dürfen. Eine strenge CSP blockiert eingeschleuste Skripte vollständig: Selbst wenn es einem Angreifer gelingt, ein Script-Tag in Ihr HTML einzufügen (durch eine Schwachstelle in Ihrem CMS oder eine kompromittierte Drittanbieter-Bibliothek), lehnt der Browser die Ausführung einfach ab.

Ohne CSP ist Ihre Website anfällig für Cross-Site-Scripting (XSS). XSS steht konsequent in den OWASP Top 10 der kritischsten Webanwendungs-Sicherheitsrisiken und steckt hinter den meisten Checkout-Manipulationen: Ein in Ihre Zahlungsseite injiziertes Skript sendet Kartennummern an den Server des Angreifers, während die Transaktion für alle Beteiligten normal aussieht.

Eine strenge Ausgangskonfiguration für eine Website, die nur eigene Ressourcen lädt: Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'. Falls Sie externe Schriften, Analysetools oder ein Zahlungs-Widget verwenden, müssen diese Quellen explizit aufgelistet werden.

2. Strict-Transport-Security (HSTS)

HSTS weist Browser an, für Ihre Domain immer HTTPS zu verwenden, für einen definierten Zeitraum, und jede HTTP-Verbindung einschließlich Weiterleitungen abzulehnen. Ohne HSTS kann ein Angreifer im selben Netzwerk (ein öffentlicher WLAN-Hotspot, ein kompromittierter Router) die erste Anfrage abfangen und die Verbindung auf einfaches HTTP herabstufen, bevor die Weiterleitung erfolgt.

Der Header lautet: Strict-Transport-Security: max-age=31536000; includeSubDomains. Die max-age entspricht einem Jahr, dem Minimum, das Google für die HSTS-Preload-Berechtigung empfiehlt. Fügen Sie preload zur Direktive hinzu und melden Sie Ihre Domain in der Browser-Preload-Liste an, um Nutzer auch beim allerersten Besuch zu schützen.

3. X-Frame-Options

Dieser Header verhindert, dass Ihre Seite in einem <iframe> einer anderen Website eingebettet wird. Ohne ihn kann ein Angreifer Ihre Login-Seite unsichtbar in seine eigene Seite laden und gefälschte UI-Elemente darüber legen. Der Nutzer glaubt, auf Ihren Button zu klicken, klickt aber auf den des Angreifers. Dies nennt sich Clickjacking.

Die Lösung ist eine einzige Zeile: X-Frame-Options: DENY (oder SAMEORIGIN, wenn Sie eigene Seiten einbetten). Die CSP-Direktive frame-ancestors ist das moderne Äquivalent und überschreibt X-Frame-Options, wenn beide vorhanden sind.

4. X-Content-Type-Options

Browser versuchen hilfreich zu sein, indem sie den Typ einer Ressource erraten, wenn der Server ihn nicht klar deklariert. Dies nennt sich MIME-Sniffing und ist ein Sicherheitsproblem: Ein Bild-Upload, der tatsächlich ein Skript ist, kann ausgeführt werden, wenn der Browser entscheidet, dass er wie JavaScript aussieht.

X-Content-Type-Options: nosniff schaltet dieses Raten vollständig ab. Es ist der einfachste Header in dieser Liste: eine Zeile, keine Konfiguration, keine Nebenwirkungen.

5. Referrer-Policy

Wenn ein Nutzer einem Link von Ihrer Website zu einer anderen folgt, sendet der Browser einen Referer-Header mit der URL der Seite, von der er kam. Wenn Ihre URLs sensible Daten enthalten (ein Passwort-Reset-Token, eine Sitzungskennung, eine Bestellreferenz), gelangen diese Daten zur Zielwebsite.

Referrer-Policy: strict-origin-when-cross-origin ist der sichere Standard: Er sendet den Ursprung (Ihren Domainnamen, keinen Pfad) an externe Websites und die vollständige URL an Ihre eigene Domain. Die privateste Option ist no-referrer, aber das beeinträchtigt einige Analyse-Integrationen.

Wie Sie Ihre Website prüfen

Am schnellsten öffnen Sie die Entwicklertools Ihres Browsers (F12), laden Ihre Startseite, gehen zum Tab „Netzwerk", klicken auf die erste Anfrage und schauen in den Abschnitt „Antwortheader". Oder verwenden Sie den Noroshi: Erstellen Sie ein kostenloses Konto, fügen Sie Ihre Domain hinzu, und der Scanner prüft alle fünf Header, bewertet sie und erklärt genau, was Sie hinzufügen müssen und wo.

Wo Sie sie setzen

Security-Header werden auf dem Webserver gesetzt, nicht in Ihrem CMS. Wo genau, hängt von Ihrer Hosting-Konfiguration ab:

Apache: in Ihrer .htaccess-Datei oder httpd.conf mit Header always set-Direktiven. Das Modul mod_headers muss aktiviert sein.
Nginx: in Ihrem Server-Block mit add_header-Direktiven. Platzieren Sie diese im server- oder location-Block, der Ihre Website verarbeitet.
Caddy: in Ihrer Caddyfile mit der header-Direktive. Caddy setzt X-Content-Type-Options: nosniff automatisch, die anderen müssen manuell hinzugefügt werden.
Cloudflare oder ein anderer Proxy: Manche Proxies ermöglichen es, Antwortheader über ihr Dashboard hinzuzufügen (Cloudflare: Transform Rules, Modify Response Header). Das ist die einfachste Option, wenn Sie die Server-Konfiguration nicht anpassen können.
WordPress: Plugins wie Wordfence, Headers Security Advanced und HSTS Preload setzen Header ohne Server-Zugriff. Das ist ein vernünftiger Fallback, wenn Ihr Hosting-Anbieter die Server-Konfiguration kontrolliert.

Was Sie von Ihrem Score erwarten können

Das Hinzufügen aller fünf Header hebt einen Noroshi-Sicherheitsscore typischerweise vom Bereich 40-60 in den Bereich 70-80 in einer einzigen Sitzung. Sie sind nicht das Einzige, was zählt (TLS-Konfiguration, DNS, offene Ports und exponierte Dateien fließen alle in den Score ein), bieten aber das beste Verhältnis von Aufwand zu Ergebnis für die meisten Websites.

Eine gut konfigurierte Website erregt keine Aufmerksamkeit. Automatisierte Scanner sondieren täglich Millionen von Websites auf fehlende Header, offene Ports und bekannte Software-Schwachstellen. Eine Website, die die richtigen Header sendet, wird schneller übergangen und seltener angegriffen. Das ist keine Sicherheit durch Verschleierung: Es macht die leichten Treffer einfach nicht verfügbar.

Kontinuierliche Überwachung

Header können sich verschlechtern. Ein CMS-Update, ein neues Plugin, eine Server-Migration oder eine Konfigurationsänderung durch Ihren Hosting-Anbieter können einen Header, der gestern vorhanden war, stillschweigend entfernen. Der Noroshi-Scanner prüft alle fünf Header bei jedem Scan und benachrichtigt Sie sofort, wenn einer fehlt, damit ein Wartungsfenster nicht unbeabsichtigt zu einem Sicherheitsfenster wird.

Erstellen Sie ein kostenloses Konto, fügen Sie Ihre Domain hinzu und sehen Sie Ihren aktuellen Header-Score in wenigen Minuten. Kostenloser Plan, keine Kreditkarte erforderlich.

Geschrieben von David Hildering, dem Entwickler hinter Noroshi. Mehr über Noroshi.