Was sind HTTP Security Headers?
Wenn ein Browser eine Website aufruft, sendet der Webserver neben dem HTML-Inhalt auch HTTP-Response-Headers. Security Headers sind spezielle Anweisungen innerhalb dieser Antwort, die dem Browser mitteilen, wie er mit den empfangenen Inhalten umgehen soll. Sie funktionieren wie Sicherheitsregeln, die der Browser automatisch durchsetzt.
Das Prinzip ist einfach: Anstatt darauf zu vertrauen, dass Angreifer keinen schädlichen Code einschleusen, weist der Server den Browser an, bestimmte Aktionen von vornherein zu blockieren. Selbst wenn ein Angreifer es schafft, schädliches JavaScript in Ihre Seite einzuschleusen, kann eine Content-Security-Policy die Ausführung dieses Codes verhindern.
Security Headers werden in der Serverkonfiguration gesetzt, nicht im Quellcode Ihrer Website. Das bedeutet: Sie können den Schutz Ihrer gesamten Website verbessern, ohne eine einzige Zeile HTML, CSS oder JavaScript zu ändern. Die Konfiguration erfolgt in der .htaccess (Apache), der nginx.conf (Nginx) oder im Control Panel Ihres Hosters.
Content-Security-Policy (CSP): Der mächtigste Header
Die Content-Security-Policy ist der umfangreichste und wirkungsvollste Security Header. Sie definiert präzise, von welchen Quellen der Browser Ressourcen laden darf: Scripts, Stylesheets, Bilder, Fonts, iframes und mehr. Eine korrekt konfigurierte CSP kann Cross-Site-Scripting-Angriffe nahezu vollständig unterbinden.
Grundlegende CSP-Konfiguration
Eine grundlegende CSP sieht so aus: Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; Diese Policy erlaubt nur Ressourcen von der eigenen Domain. Externe Scripts werden blockiert. In der Praxis müssen Sie die Policy an Ihre tatsächlich verwendeten Dienste anpassen: Wenn Sie eine externe Schriftart verwenden, muss deren Domain in font-src erlaubt werden.
CSP schrittweise einführen
Eine zu restriktive CSP kann Funktionalitäten Ihrer Website beschädigen. Daher empfiehlt sich eine schrittweise Einführung:
- Beginnen Sie mit Content-Security-Policy-Report-Only statt Content-Security-Policy. Der Browser meldet Verstöße, blockiert aber nichts.
- Richten Sie einen Report-Endpunkt ein, um die Verstöße zu sammeln und zu analysieren.
- Passen Sie die Policy an, bis alle legitimen Ressourcen erlaubt sind.
- Schalten Sie erst dann auf den Enforce-Modus um.
- Überwachen Sie die CSP dauerhaft, da jedes neue Script oder Plugin die Policy verletzen kann.
Die Direktiven 'unsafe-inline' und 'unsafe-eval' in script-src heben den XSS-Schutz der CSP weitgehend auf. Wenn möglich, verwenden Sie stattdessen Nonces oder Hashes für inline Scripts. XICTRAQ erkennt diese Schwachstellen und meldet sie als Konfigurationsmangel.
Strict-Transport-Security (HSTS)
HSTS weist den Browser an, alle künftigen Verbindungen zur Website ausschließlich über HTTPS herzustellen. Selbst wenn ein Nutzer manuell http:// eingibt, leitet der Browser automatisch auf HTTPS um, ohne den Server zu kontaktieren. Das verhindert sogenannte Downgrade-Angriffe und schützt vor Man-in-the-Middle-Angriffen in unsicheren Netzwerken wie öffentlichem WLAN.
Die empfohlene Konfiguration lautet: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload. Die max-age von 31536000 Sekunden entspricht einem Jahr. includeSubDomains schützt alle Subdomains. Das preload-Attribut ermöglicht die Aufnahme in die HSTS-Preload-Liste der Browser, wodurch der Schutz bereits beim allerersten Besuch greift.
Aktivieren Sie HSTS erst, wenn HTTPS auf Ihrer gesamten Website einwandfrei funktioniert. Ein fehlerhaft konfigurierter HSTS-Header kann dazu führen, dass Ihre Website über mehrere Monate hinweg nicht erreichbar ist, da der Browser die max-age-Einstellung strikt durchsetzt und kein Zurück auf HTTP erlaubt.
X-Content-Type-Options
Dieser Header verhindert, dass Browser den MIME-Type einer Datei erraten, ein Vorgang der als MIME-Sniffing bezeichnet wird. Ohne diesen Header könnte ein Angreifer eine als Bild getarnte JavaScript-Datei einschleusen, die der Browser trotzdem als Script ausführt.
Die Konfiguration ist denkbar einfach: X-Content-Type-Options: nosniff. Dieser Header verursacht keine Kompatibilitätsprobleme und sollte auf jeder Website gesetzt sein. Er ist der einfachste Einstieg in die Welt der Security Headers.
X-Frame-Options: Schutz vor Clickjacking
X-Frame-Options kontrolliert, ob Ihre Website in einem iframe eingebettet werden darf. Bei einem Clickjacking-Angriff bettet ein Angreifer Ihre Website unsichtbar über einer manipulierten Seite ein. Wenn der Nutzer auf einen scheinbar harmlosen Button klickt, führt er in Wirklichkeit eine Aktion auf Ihrer Website aus, beispielsweise eine Überweisung oder eine Kontoeinstellung.
X-Frame-Options: DENY verhindert jede Einbettung. X-Frame-Options: SAMEORIGIN erlaubt Einbettung nur von der eigenen Domain. Für die meisten Websites ist DENY die sicherere Wahl. Wenn Sie Ihre Seite in eigene iframes einbetten müssen, verwenden Sie SAMEORIGIN.
Die modernere Alternative ist die frame-ancestors-Direktive in der CSP, die flexiblere Konfigurationsmöglichkeiten bietet: Content-Security-Policy: frame-ancestors 'self' entspricht X-Frame-Options: SAMEORIGIN.
Referrer-Policy
Wenn ein Nutzer von Ihrer Website zu einer anderen navigiert, sendet der Browser standardmäßig die vollständige URL als Referrer-Information mit. Das kann sensible Informationen preisgeben: interne URL-Strukturen, Suchparameter oder sogar Session-IDs in der URL.
Referrer-Policy: strict-origin-when-cross-origin ist die empfohlene Einstellung. Bei Navigation innerhalb Ihrer Domain wird der vollständige Referrer gesendet, was für Ihre eigene Analyse nützlich bleibt. Bei Navigation zu externen Websites wird nur die Origin (also die Domain ohne Pfad) übermittelt. Bei Wechsel von HTTPS zu HTTP wird gar kein Referrer gesendet.
Permissions-Policy: Browser-APIs einschränken
Die Permissions-Policy (ehemals Feature-Policy) kontrolliert, welche Browser-Funktionen Ihre Website nutzen darf. Dazu gehören Kamera, Mikrofon, Geolocation, Payment API, USB-Zugriff und viele weitere APIs. Eine strenge Permissions-Policy stellt sicher, dass kompromittierte Third-Party-Scripts keinen Zugriff auf sensible Browser-APIs erhalten.
Beispiel: Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=() deaktiviert Kamera, Mikrofon, Geolocation und Payment API vollständig. Wenn Ihre Website eine bestimmte API benötigt, erlauben Sie sie gezielt: Permissions-Policy: geolocation=(self).
Security Headers konfigurieren: Apache und Nginx
Apache-Konfiguration (.htaccess)
Header set X-Content-Type-Options "nosniff"
Header set X-Frame-Options "SAMEORIGIN"
Header set Referrer-Policy "strict-origin-when-cross-origin"
Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
Header set Permissions-Policy "camera=(), microphone=(), geolocation=()"
Header set Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:;"Nginx-Konfiguration
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 Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:;" always;Das Keyword 'always' in Nginx stellt sicher, dass die Header auch bei Fehler-Antworten (404, 500 usw.) gesendet werden. Ohne 'always' werden die Header nur bei erfolgreichen Antworten (2xx, 3xx) angehängt.
Häufige Fehler bei Security Headers
- Zu lockere CSP: Eine CSP mit 'unsafe-inline' und 'unsafe-eval' bietet kaum Schutz gegen XSS-Angriffe
- Fehlende includeSubDomains bei HSTS: Ohne dieses Attribut sind Subdomains weiterhin anfällig für Downgrade-Angriffe
- Doppelte Header: Manche Server senden denselben Header mehrfach mit unterschiedlichen Werten, was zu unvorhersehbarem Verhalten führt
- Header nur auf der Startseite: Security Headers müssen auf allen Seiten gesetzt sein, nicht nur auf ausgewählten
- Veraltete Header verwenden: X-XSS-Protection gilt als veraltet und kann in bestimmten Browsern sogar Sicherheitslücken öffnen. Verwenden Sie stattdessen eine CSP.
Security Headers und SEO-Auswirkungen
Security Headers haben auch indirekte Auswirkungen auf die Suchmaschinenoptimierung. Google bevorzugt sichere Websites und berücksichtigt HTTPS als Ranking-Signal. Eine korrekt konfigurierte HSTS-Policy signalisiert Suchmaschinen, dass Ihre Website dauerhaft über HTTPS erreichbar ist. Fehlerhafte Konfigurationen können zu Browser-Warnungen führen, die Besucher abschrecken und die Absprungrate erhöhen.
Darüber hinaus schützt eine strenge CSP vor Angriffen, die Ihre Website manipulieren und schädliche Inhalte einschleusen könnten. Websites, die von Malware betroffen sind, werden von Google mit einer Warnmeldung in den Suchergebnissen versehen, was den Traffic drastisch reduziert. Gute Security Headers sind also nicht nur ein Sicherheitsthema, sondern auch eine SEO-Maßnahme. Mehr zu technischem SEO finden Sie in unserem Beitrag zum automatisierten SEO-Monitoring.
Security Headers kontinuierlich überwachen
Die einmalige Konfiguration von Security Headers reicht nicht aus. Server-Updates, Hosting-Migrationen, CDN-Konfigurationsänderungen oder neue Dienste können dazu führen, dass Header versehentlich entfernt oder abgeschwächt werden. Ohne kontinuierliche Überwachung bemerken Sie das erst, wenn es zu spät ist.
Das Security-Modul von XICTRAQ prüft Ihre Headers in konfigurierbaren Intervallen und bewertet nicht nur deren Existenz, sondern auch die Konfigurationsqualität. Eine CSP mit 'unsafe-inline' erhält eine niedrigere Bewertung als eine streng konfigurierte Policy. Sie erhalten konkrete Empfehlungen zur Verbesserung und werden sofort benachrichtigt, wenn sich etwas ändert.
Die Integration in das übergreifende Website-Monitoring bedeutet, dass Security-Header-Daten im Kontext anderer Metriken betrachtet werden können. Wenn nach einem Server-Update plötzlich Headers fehlen, korreliert XICTRAQ dies mit dem Zeitpunkt der Änderung und liefert Ihnen die nötigen Informationen zur schnellen Behebung.
Häufig gestellte Fragen zu Security Headers
Welche Security Headers sollte ich zuerst implementieren?
Können Security Headers meine Website beschädigen?
Brauche ich Security Headers, wenn ich HTTPS verwende?
Wie prüfe ich, welche Security Headers meine Website hat?
Wie oft ändern sich die Empfehlungen für Security Headers?
Beeinflussen Security Headers die Website-Performance?
Dieser Artikel basiert auf Daten von: (Google), (Scott Helme).