Security Header einfach erklärt: CSP und HSTS verständlich und praxisnah

Kategorien: Allgemein

Eine Website kann technisch einwandfrei funktionieren, gut aussehen und trotzdem angreifbar sein. Viele Sicherheitslücken im Web entstehen nicht durch exotische Hackertricks, sondern dadurch, dass Browser nicht genau wissen, was sie tun dürfen und was nicht. Genau hier setzen Security Header an: kleine Zusatzinformationen, die Ihr Server mit jeder Antwort an den Browser schickt und die dessen Verhalten gezielt absichern.

In diesem Artikel erfahren Sie, was Security-Header sind, wie die beiden wichtigsten Vertreter HSTS und CSP funktionieren und wie Sie beide Schritt für Schritt und ohne böse Überraschungen einführen. Dazu gibt es fertige Konfigurationsbeispiele für Nginx und Apache sowie eine Checkliste zum Abhaken.

Das Wichtigste in Kürze

• Security-Header sind HTTP-Antwortzeilen, die dem Browser Sicherheitsregeln für Ihre Seite mitgeben.
• HSTS zwingt den Browser dazu, Ihre Seite ausschließlich verschlüsselt per HTTPS aufzurufen.
• CSP legt fest, welche Inhalte (Skripte, Bilder, Schriften, Frames) die Seite überhaupt laden darf, und ist damit ein starker Schutz gegen Cross-Site-Scripting.
• Beide Header lassen sich mit wenigen Zeilen Serverkonfiguration einrichten, sollten aber schrittweise eingeführt werden.
• Mit kostenlosen Online-Tests prüfen Sie in Sekunden, ob Ihre Konfiguration greift.

Was sind Security Header überhaupt?

Wenn Ihr Browser eine Webseite aufruft, schickt der Server nicht nur den eigentlichen Inhalt (HTML, Bilder, Skripte), sondern vorab auch sogenannte HTTP-Header. Das sind Textzeilen mit Metainformationen, zum Beispiel über den Inhaltstyp, die Dateigröße oder die Zwischenspeicherung.

Ein Teil dieser Header dient ausschließlich der Sicherheit. Sie sind sozusagen die Hausordnung für den Browser:

• Darf diese Seite in einem fremden Rahmen (Frame) eingebettet werden?
• Von welchen Servern dürfen Skripte nachgeladen werden?
• Muss die Verbindung immer verschlüsselt sein?

Der Browser hält sich an diese Regeln und blockiert alles, was dagegen verstößt. Der große Vorteil: Sie müssen dafür keinen Programmcode ändern. Die Header werden zentral in der Konfiguration des Webservers (oder eines vorgeschalteten Dienstes) gesetzt und gelten sofort für die gesamte Seite.

Ein Beispiel, wie so eine Antwort aussehen kann:

HTTP/2 200
content-type: text/html; charset=UTF-8
strict-transport-security: max-age=31536000; includeSubDomains
content-security-policy: default-src 'self'
x-content-type-options: nosniff

Die letzten drei Zeilen sind Security-Header. Für den Besucher sind sie unsichtbar, für den Browser aber verbindlich.

HSTS: Immer verschlüsselt, ohne Ausnahme

Das Problem, das HSTS löst

Auch wenn Ihre Seite ein gültiges HTTPS-Zertifikat besitzt, bleibt eine Schwachstelle: Viele Besucher tippen nur it-logic.de in die Adresszeile oder folgen einem alten Link mit http://. Der Browser fragt dann zunächst unverschlüsselt an, und erst die Antwort des Servers leitet auf HTTPS um.

In diesem kurzen Moment kann ein Angreifer, etwa in einem öffentlichen WLAN, die Verbindung abfangen und manipulieren. Man spricht von einem sogenannten Downgrade-Angriff oder SSL-Stripping. Der Besucher bemerkt davon oft nichts.

Die Lösung: Strict-Transport-Security

Mit dem Header Strict-Transport-Security (kurz HSTS) teilt der Server dem Browser mit: „Für diese Domain gilt ab sofort ausschließlich HTTPS. Merke dir das für eine bestimmte Zeit.“

Der Browser speichert diese Information und stellt künftig selbstständig jede http://-Anfrage auf https:// um, noch bevor überhaupt ein unverschlüsseltes Paket das Gerät verlässt.

Ein typischer Header sieht so aus:

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

Die Bestandteile im Detail

• max-age gibt in Sekunden an, wie lange sich der Browser die Regel merken soll. 31536000 Sekunden entsprechen einem Jahr. Bei jedem Seitenaufruf wird die Frist erneuert.
• includeSubDomains dehnt die Regel auf alle Subdomains aus, etwa shop.beispiel.de oder mail.beispiel.de.
• preload signalisiert, dass Sie die Domain in die HSTS-Preload-Liste der Browserhersteller aufnehmen lassen möchten. Dann kennen Browser die Regel schon vor dem allerersten Besuch.

Wichtig zu wissen

• HSTS wird vom Browser nur über HTTPS akzeptiert. Über eine unverschlüsselte Verbindung gesendet, wird der Header ignoriert.
• Beim allerersten Besuch einer Domain kennt der Browser die Regel noch nicht. Dieses Restrisiko schließt nur die Preload-Liste.
• Die Preload-Aufnahme setzt unter anderem voraus: ein gültiges Zertifikat, eine Weiterleitung von HTTP auf HTTPS, includeSubDomains, preload und eine max-age von mindestens einem Jahr. Ein Austrag aus der Liste dauert Monate. Gehen Sie diesen Schritt also nur dann, wenn wirklich alle Subdomains dauerhaft HTTPS-fähig sind.

So führen Sie HSTS sicher ein

Ein zu aggressiver HSTS-Start ist einer der häufigsten Fehler. Wenn Sie includeSubDomains setzen und eine vergessene Subdomain nur per HTTP erreichbar ist, wird sie für Besucher plötzlich unerreichbar. Gehen Sie deshalb stufenweise vor:

1. Stellen Sie sicher, dass die gesamte Seite inklusive aller Ressourcen über HTTPS funktioniert und das Zertifikat automatisch erneuert wird.
2. Richten Sie eine dauerhafte Weiterleitung (301) von HTTP auf HTTPS ein.
3. Starten Sie mit einer kurzen Laufzeit, zum Beispiel max-age=300 (fünf Minuten), und prüfen Sie, ob alles funktioniert.
4. Erhöhen Sie schrittweise auf einen Tag, eine Woche, einen Monat und schließlich ein Jahr.
5. Ergänzen Sie includeSubDomains erst, wenn Sie jede Subdomain geprüft haben.
6. Überlegen Sie preload ganz zuletzt und nur, wenn Sie die Folgen verstanden haben.

CSP: Die Inhaltsrichtlinie für Ihre Seite

Das Problem, das CSP löst

Die häufigste Angriffsart auf Webseiten ist Cross-Site-Scripting (XSS). Dabei schleust ein Angreifer eigenen JavaScript-Code in Ihre Seite ein, etwa über ein Kommentarfeld, ein Suchfeld oder eine verwundbare Erweiterung. Der Browser kann nicht unterscheiden, ob ein Skript von Ihnen stammt oder von einem Angreifer, und führt beides aus.

Die Folgen reichen vom Diebstahl von Sitzungsdaten über untergeschobene Formulare bis zum Mitschneiden von Eingaben.

Die Lösung: Content-Security-Policy

Mit der Content Security Policy (CSP) erstellen Sie eine Positivliste: Sie legen fest, woher der Browser Inhalte laden und welche Aktionen er ausführen darf. Alles, was nicht auf der Liste steht, wird blockiert. Selbst wenn ein Angreifer Code einschleusen kann, verweigert der Browser dessen Ausführung.

Ein einfaches Beispiel:

Content-Security-Policy: default-src 'self'; img-src 'self' https://cdn.beispiel.de; script-src 'self'

Übersetzt heißt das: Standardmäßig darf alles nur von der eigenen Domain kommen. Bilder sind zusätzlich vom CDN cdn.beispiel.de erlaubt, Skripte ausschließlich von der eigenen Domain.

Die wichtigsten Direktiven

Eine CSP besteht aus einzelnen Regeln, den Direktiven, getrennt durch Semikolons:

• default-src: die Grundregel für alle Inhaltstypen, für die keine eigene Direktive gesetzt ist.
• script-src: erlaubte Quellen für JavaScript. Die wichtigste Direktive für den XSS-Schutz.
• style-src: erlaubte Quellen für CSS.
• img-src: erlaubte Quellen für Bilder.
• font-src: erlaubte Quellen für Schriftarten.
• connect-src: erlaubte Ziele für Anfragen per JavaScript (zum Beispiel fetch oder XMLHttpRequest).
• frame-src: Quellen, die als eingebettete Frames erscheinen dürfen, etwa ein YouTube-Video oder eine Karte.
• frame-ancestors: bestimmt, wer Ihre Seite einbetten darf. Das ist der moderne Ersatz für den älteren Header X-Frame-Options und schützt vor Clickjacking.
• form-action: erlaubte Ziele für Formulare.
• base-uri: schränkt das <base>-Element ein, über das Angreifer sonst relative Links umbiegen könnten.
• object-src: Plug-in-Inhalte. Hier ist 'none' fast immer die richtige Wahl.
• upgrade-insecure-requests: weist den Browser an, unsichere Ressourcen automatisch über HTTPS anzufordern.

Gut zu wissen: frame-ancestors, base-uri und form-action erben nicht von default-src. Sie müssen bei Bedarf immer ausdrücklich gesetzt werden.

Die wichtigsten Quellangaben

• 'self': die eigene Domain (gleiches Protokoll, gleicher Host, gleicher Port).
• 'none': gar keine Quelle erlaubt.
• https://cdn.beispiel.de: eine bestimmte Domain.
• https:: jede beliebige HTTPS-Quelle (sehr großzügig, nur im Notfall verwenden).
• data:: Inhalte, die direkt in die Seite eingebettet sind, etwa kleine Bilder.
• 'unsafe-inline': erlaubt Inline-Skripte oder Inline-Styles. Bei script-src hebelt das den XSS-Schutz weitgehend aus und sollte vermieden werden.
• 'unsafe-eval': erlaubt Code-Ausführung aus Zeichenketten (eval). Ebenfalls riskant.
• 'nonce-…' und 'sha256-…': erlauben gezielt einzelne Inline-Skripte (siehe unten).

Inline-Skripte sicher erlauben: Nonce und Hash

Viele Seiten enthalten kleine Skripte direkt im HTML. Statt pauschal 'unsafe-inline' zu erlauben, gibt es zwei saubere Wege:

Nonce: Der Server erzeugt bei jeder Anfrage eine zufällige, einmalig gültige Zeichenfolge, trägt sie in den Header und in das erlaubte Skript ein:

Content-Security-Policy: script-src 'nonce-r4nd0mW3rt'

<script nonce="r4nd0mW3rt">
  console.log("Dieses Skript ist ausdrücklich erlaubt");
</script>

Ein Angreifer kennt den Wert nicht und kann dadurch keine eigenen Skripte ausführen lassen. Wichtig: Der Wert muss pro Seitenaufruf neu und nicht erratbar sein.

Hash: Sie berechnen den SHA-256-Hash eines unveränderlichen Skripts und tragen ihn in den Header ein. Der Browser vergleicht den Hash und führt das Skript nur bei Übereinstimmung aus. Das eignet sich für statische Seiten.

Die goldene Regel: erst beobachten, dann blockieren

Eine CSP, die zu streng startet, kann Ihre Seite lahmlegen: Schriften fehlen, das Kontaktformular tut nichts mehr, eingebettete Karten bleiben leer. Dafür gibt es den Report-Only-Modus:

Content-Security-Policy-Report-Only: default-src 'self'; report-to csp-endpoint

In diesem Modus blockiert der Browser nichts, meldet aber jeden Verstoß in der Entwicklerkonsole und optional an einen von Ihnen angegebenen Meldepunkt. So sehen Sie in Ruhe, was Ihre Richtlinie betreffen würde, bevor sie scharf geschaltet wird.

Schritt für Schritt zur eigenen CSP

1. Bestandsaufnahme: Öffnen Sie Ihre Seite im Browser mit den Entwicklertools (Reiter „Netzwerk“) und notieren Sie, von welchen Domains Skripte, Styles, Bilder, Schriften und Frames geladen werden.
2. Report-Only starten: Setzen Sie eine erste Richtlinie als Content-Security-Policy-Report-Only.
3. Konsole auswerten: Jede Meldung zeigt, welche Quelle fehlt. Entscheiden Sie bewusst, ob diese Quelle wirklich erlaubt sein soll.
4. Inline-Code aufräumen: Verschieben Sie Skripte und Styles wenn möglich in eigene Dateien oder nutzen Sie Nonces.
5. Scharf schalten: Wenn die Konsole sauber bleibt, benennen Sie den Header in Content-Security-Policy um.
6. Dauerhaft pflegen: Prüfen Sie die Richtlinie nach jeder Änderung an Plug-ins, Themes, Trackern oder eingebetteten Diensten.

Eine solide Ausgangsbasis für eine statische Seite könnte so aussehen:

Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data:; font-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'self'; upgrade-insecure-requests

Besonderheiten bei WordPress

WordPress macht eine strenge CSP anspruchsvoll, weil Themes und Plug-ins häufig Inline-Skripte und Inline-Styles erzeugen. Praxistipps:

• Starten Sie unbedingt im Report-Only-Modus und testen Sie sowohl das Frontend als auch den Administrationsbereich.
• Der Admin-Bereich und der Block-Editor benötigen oft großzügigere Regeln als die öffentliche Seite. Setzen Sie die CSP daher gegebenenfalls nur für das Frontend.
• Externe Dienste wie Google Fonts, YouTube, Karten oder Statistik-Tools müssen einzeln freigegeben werden. Aus Datenschutzsicht lohnt es sich ohnehin, Schriften lokal einzubinden.
• Jedes neue Plug-in kann die Richtlinie wieder brechen. Planen Sie nach Updates einen kurzen Funktionstest ein.

Weitere nützliche Security Header im Überblick

CSP und HSTS sind die Schwergewichte, aber ein paar weitere Header sind mit minimalem Aufwand gesetzt und bringen echten Mehrwert:

• X-Content-Type-Options: nosniff verhindert, dass der Browser Dateitypen „errät“ und dadurch harmlos wirkende Dateien als Skripte ausführt.
• Referrer-Policy: strict-origin-when-cross-origin begrenzt, wie viel von der besuchten Adresse an externe Seiten weitergegeben wird. Gut für den Datenschutz.
• Permissions-Policy schaltet Browserfunktionen wie Kamera, Mikrofon oder Standort für Ihre Seite ab, falls sie nicht benötigt werden. Beispiel: camera=(), microphone=(), geolocation=().
• X-Frame-Options: SAMEORIGIN schützt vor Clickjacking. Moderne Browser nutzen dafür frame-ancestors in der CSP, der ältere Header schadet aber als Ergänzung nicht.
• Cross-Origin-Opener-Policy und verwandte Header trennen Ihre Seite von fremden Fenstern ab. Das ist besonders für anspruchsvolle Anwendungen interessant.

Der frühere Header X-XSS-Protection gilt als veraltet. Moderne Browser ignorieren ihn oder haben den zugehörigen Filter entfernt. Sie können ihn weglassen und stattdessen auf eine gute CSP setzen.

Konfigurationsbeispiele

Nginx

Tragen Sie die Header im server-Block Ihrer Seite ein:

# Security-Header für die gesamte Seite
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Content-Security-Policy "default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'" always;

Das Schlüsselwort always sorgt dafür, dass die Header auch bei Fehlerseiten (zum Beispiel 404) gesendet werden. Beachten Sie außerdem: In Nginx werden add_header-Anweisungen aus einer höheren Ebene nicht übernommen, sobald auf einer tieferen Ebene (etwa in einem location-Block) eigene add_header-Zeilen stehen. Wiederholen Sie die Header dort bei Bedarf.

Apache

Aktivieren Sie das Modul mod_headers und ergänzen Sie in der Konfiguration oder in der .htaccess:

# Security-Header für die gesamte Seite
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
Header always set Content-Security-Policy "default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'"

Hinter einem Proxy oder CDN

Setzen Sie die Header möglichst an einer Stelle. Wenn sowohl der Ursprungsserver als auch ein vorgeschalteter Dienst Header ergänzen, entstehen Dubletten oder widersprüchliche Werte. Bei doppelten CSP-Headern gilt zudem: Der Browser wendet alle Richtlinien an, und die jeweils strengere setzt sich durch.

So prüfen Sie Ihre Konfiguration

Nach der Einrichtung sollten Sie das Ergebnis immer kontrollieren:

• Kommandozeile: Mit curl -I https://ihre-domain.de sehen Sie alle Antwort-Header auf einen Blick.
• Entwicklertools des Browsers: Im Reiter „Netzwerk“ finden Sie die Header der Antwort, in der „Konsole“ die Meldungen zu CSP-Verstößen.
• Online-Tests: Dienste wie securityheaders.com oder das Mozilla Observatory bewerten Ihre Header automatisch und geben konkrete Verbesserungsvorschläge. Für HSTS-Preload gibt es zudem eine offizielle Prüfseite unter hstspreload.org.

Häufige Fehler und wie Sie sie vermeiden

• HSTS zu früh mit langer Laufzeit: Beginnen Sie mit kurzen Zeiten und steigern Sie sich. Ein Fehler lässt sich sonst über Monate nicht zurücknehmen.
• 'unsafe-inline' bei script-src: Das fühlt sich bequem an, entwertet den XSS-Schutz der CSP aber stark. Nutzen Sie stattdessen Nonces oder Hashes.
• Zu großzügige Platzhalter: Eine Angabe wie https: oder * erlaubt nahezu alles und schützt kaum noch.
• CSP ungetestet scharf geschaltet: Immer zuerst im Report-Only-Modus beobachten.
• Header nur auf der Startseite: Stellen Sie sicher, dass die Regeln für alle Pfade, Fehlerseiten und Subdomains gelten.
• Vergessene Anpassung nach Änderungen: Neue Plug-ins, Tracker oder eingebettete Dienste benötigen oft neue Freigaben in der CSP.

Checkliste zum Abhaken

• Die gesamte Seite ist über HTTPS erreichbar, das Zertifikat erneuert sich automatisch.
• HTTP wird dauerhaft auf HTTPS umgeleitet.
• HSTS ist gesetzt und wurde schrittweise auf mindestens ein Jahr erhöht.
• includeSubDomains wird nur verwendet, wenn alle Subdomains HTTPS unterstützen.
• Eine CSP wurde zuerst im Report-Only-Modus getestet und anschließend aktiviert.
• Für Skripte wird kein pauschales 'unsafe-inline' verwendet.
• object-src 'none', base-uri und frame-ancestors sind gesetzt.
• X-Content-Type-Options, Referrer-Policy und Permissions-Policy sind ergänzt.
• Das Ergebnis wurde mit curl und einem Online-Test überprüft.
• Nach jeder größeren Änderung an der Seite wird die Konfiguration erneut getestet.

Häufige Fragen

Ersetzen Security-Header andere Sicherheitsmaßnahmen? Nein. Sie sind eine zusätzliche Schutzschicht. Aktuelle Software, sichere Passwörter, saubere Eingabeprüfung und regelmäßige Updates bleiben unverzichtbar. Security-Header begrenzen den Schaden, falls doch einmal etwas durchrutscht.

Verlangsamen Security-Header meine Seite? Nein. Die Header sind nur wenige Bytes groß und haben praktisch keinen Einfluss auf die Ladezeit. Eine saubere CSP kann sogar helfen, unnötige Drittanbieter-Ressourcen aufzudecken.

Brauche ich HSTS, wenn ich bereits auf HTTPS umleite? Ja, es lohnt sich. Die Weiterleitung schützt nur, wenn die erste unverschlüsselte Anfrage nicht abgefangen wird. HSTS schließt genau diese Lücke für wiederkehrende Besucher.

Kann eine falsche CSP meine Seite kaputt machen? Ja, deshalb der Weg über Report-Only. So erkennen Sie Probleme, ohne dass Besucher etwas davon merken.

Muss ich das alles selbst konfigurieren? Nicht zwingend. Viele Hoster und CDN-Anbieter bieten Einstellungen für Security-Header an. Prüfen Sie aber immer, was tatsächlich beim Besucher ankommt.

Fazit

Security-Header gehören zu den wirkungsvollsten Sicherheitsmaßnahmen im Verhältnis zum Aufwand. HSTS stellt sicher, dass Verbindungen zu Ihrer Seite konsequent verschlüsselt bleiben, und CSP nimmt Angreifern die Möglichkeit, eingeschleusten Code auszuführen. Beide verlangen etwas Sorgfalt bei der Einführung, belohnen Sie dafür aber mit einem deutlich robusteren Auftritt.

Beginnen Sie klein: Setzen Sie HSTS mit kurzer Laufzeit, starten Sie die CSP im Report-Only-Modus und steigern Sie die Strenge Schritt für Schritt. Nach einigen Tagen Beobachtung haben Sie eine Konfiguration, die zu Ihrer Seite passt und Besucher wie Betreiber spürbar besser schützt.