Security Header setzen: HSTS und CSP Schritt für Schritt

Deine Website läuft, die Seiten laden, die Kunden melden sich. Trotzdem fehlt bei vielen KMU ein Schutz, der in wenigen Minuten eingerichtet ist und eine ganze Reihe typischer Angriffe ausbremst: richtig gesetzte Security Header. Sie sind kleine Anweisungen, die dein Server bei jeder Antwort mitschickt und die dem Browser sagen, wie er mit deiner Seite umgehen soll. In dieser Anleitung zeigen wir dir Schritt für Schritt, wie du Security Header setzt, welche wirklich wichtig sind und wie du die Content Security Policy (CSP) sicher einführst, ohne deine Seite zu zerschiessen.

Du brauchst dafür keine tiefen Sicherheitskenntnisse. Du brauchst Zugriff auf die Konfiguration deines Webservers (Nginx oder Apache) oder deines Hostings, und etwa eine Stunde Zeit für einen sauberen Test.

Was sind Security Header und warum brauchst du sie?

Jede Antwort deines Webservers besteht aus zwei Teilen: dem eigentlichen Inhalt (HTML, Bilder, Skripte) und den HTTP-Headern, also Zusatzinformationen zur Antwort. Security Header sind Header, die das Sicherheitsverhalten des Browsers steuern. Der Browser setzt sie direkt beim Besucher durch. Das ist ihr grosser Vorteil: Du musst dafür keinen Code deiner Seite umschreiben.

Gerade für KMU lohnt sich das, weil viele Websites über Jahre gewachsen sind. Alte Skripte, eingebundene Drittanbieter, Kontaktformulare und Tracking-Tools bieten Angreifern Angriffsfläche. Wenn Security Header richtig gesetzt sind, hilft das zum Beispiel gegen:

• Cross-Site-Scripting (XSS): Fremder Code wird in deine Seite eingeschleust und im Browser deiner Besucher ausgeführt.
• Clickjacking: Deine Seite wird unsichtbar in eine fremde Seite eingebettet, damit Besucher unbewusst auf etwas klicken.
• Downgrade-Angriffe: Ein Angreifer zwingt die Verbindung von HTTPS zurück auf unverschlüsseltes HTTP.
• Datenabfluss über den Referrer: Vollständige URLs mit sensiblen Parametern landen bei fremden Seiten.

Security Header ersetzen keine Updates, keine sicheren Passwörter und keine saubere Programmierung. Sie sind eine zusätzliche Schutzschicht (Defense in Depth), die Schäden begrenzt, wenn doch einmal etwas durchrutscht.

Die wichtigsten Security Header im Überblick

Es gibt eine ganze Liste von Headern, aber für den Start reichen fünf. Diese Reihenfolge empfehlen wir, vom einfachen zum anspruchsvollen:

• Strict-Transport-Security (HSTS): Der Browser spricht mit deiner Domain nur noch über HTTPS.
• X-Content-Type-Options: Der Browser darf Dateitypen nicht «erraten», sondern hält sich an den deklarierten Typ.
• Referrer-Policy: Du steuerst, wie viel von der Herkunfts-URL an andere Seiten weitergegeben wird.
• Permissions-Policy: Du schaltest Browserfunktionen wie Kamera, Mikrofon oder Standort ab, die deine Seite nicht braucht.
• Content-Security-Policy (CSP): Du legst fest, von wo Skripte, Bilder und andere Ressourcen geladen werden dürfen. Das ist der mächtigste, aber auch heikelste Header.

Schritt 1: Ausgangslage prüfen

Bevor du Security Header setzt, schau dir an, was dein Server aktuell sendet. Das geht am schnellsten im Terminal mit curl:

curl -sI https://www.deine-domain.ch | grep -i -E 'strict-transport|content-security|x-content-type|referrer-policy|permissions-policy'

Kommt nichts zurück, setzt dein Server noch keinen dieser Header. Alternativ kannst du kostenlose Online-Scanner nutzen, die deine Domain prüfen und eine Note vergeben. Notiere dir das Ergebnis, damit du den Fortschritt später vergleichen kannst.

Schritt 2: Security Header setzen, zuerst HSTS

Der Header Strict-Transport-Security sagt dem Browser, dass er deine Domain für eine bestimmte Zeit nur noch über HTTPS aufrufen soll. Laut der MDN Web Docs ist der Parameter max-age Pflicht, er gibt die Dauer in Sekunden an. Mit includeSubDomains gilt die Regel auch für alle Subdomains.

Voraussetzung: Deine gesamte Website, inklusive aller Subdomains, läuft sauber über HTTPS, und HTTP-Anfragen werden per Weiterleitung (301 oder 308) auf HTTPS umgeleitet. Der Header wird nur über HTTPS ausgewertet, über HTTP ignorieren ihn Browser.

Beispiel für Nginx im Server-Block deiner HTTPS-Konfiguration:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Und das Gleiche für Apache (Modul mod_headers muss aktiv sein):

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

Der Wert 31536000 entspricht einem Jahr. Das Wort always sorgt dafür, dass der Header auch bei Fehlerseiten mitgeschickt wird. Mit dem Zusatz preload kannst du deine Domain später in die Preload-Listen der Browser eintragen lassen. Dafür sind mindestens ein Jahr max-age und includeSubDomains nötig. Aber Vorsicht: Das ist schwer rückgängig zu machen. Starte deshalb erst einmal ohne preload und mit einer kürzeren Laufzeit, zum Beispiel einem Tag, und erhöhe sie, wenn alles stabil läuft.

Schritt 3: Die einfachen Header ergänzen

Diese drei Security Header sind unkompliziert und brechen auf normalen Unternehmenswebsites selten etwas. Setze sie in Nginx so:

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;

Was bedeuten sie in der Praxis?

• nosniff verhindert, dass ein Browser eine hochgeladene Datei als Skript ausführt, nur weil sie danach aussieht.
• strict-origin-when-cross-origin schickt innerhalb deiner Seite den vollen Pfad mit, an fremde Seiten aber nur die Domain. Das ist ein guter Standard für Datenschutz und Analyse.
• Permissions-Policy mit leeren Klammern verbietet die genannten Funktionen komplett. Brauchst du zum Beispiel eine Standortabfrage, passt du die Zeile an.

Ein Stolperstein bei Nginx: Wenn du in einem location-Block selbst ein add_header setzt, werden die Header aus dem übergeordneten Block nicht mehr geerbt. Prüfe deshalb nach jeder Änderung mit curl, ob wirklich alle Header ankommen.

Schritt 4: Content Security Policy zuerst im Testmodus

Die Content Security Policy ist der wirkungsvollste Schutz gegen XSS, aber auch der Header, der am ehesten Dinge kaputt macht. Er blockiert alles, was nicht ausdrücklich erlaubt ist, auch den Tracking-Code oder das eingebettete Video, das du vergessen hast. Darum gilt: Nie direkt scharf schalten.

Dafür gibt es den Header Content-Security-Policy-Report-Only. Verstösse werden gemeldet, aber nicht blockiert. Du siehst also, was eine Policy kaputt machen würde, ohne dass Besucher etwas merken. Ein sinnvoller Startpunkt:

add_header Content-Security-Policy-Report-Only "default-src 'self'; img-src 'self' data:; object-src 'none'; base-uri 'self'; frame-ancestors 'self'" always;

Die einzelnen Direktiven in einfachen Worten:

• default-src 'self' ist die Grundregel: Alles darf nur von deiner eigenen Domain kommen, solange nichts anderes definiert ist.
• img-src 'self' data: erlaubt Bilder von deiner Domain und eingebettete data-URLs.
• object-src 'none' sperrt veraltete Plugin-Einbettungen.
• base-uri 'self' verhindert, dass Angreifer mit einem base-Tag die Basis aller relativen Links umbiegen.
• frame-ancestors 'self' erlaubt das Einbetten deiner Seite nur auf deiner eigenen Domain und schützt damit vor Clickjacking. Willst du gar keine Einbettung, nimm 'none'.

Öffne nun deine Website und klicke dich durch die wichtigsten Seiten: Startseite, Kontaktformular, Shop oder Terminbuchung. Öffne dabei die Entwicklerkonsole deines Browsers (F12). Jeder Verstoss wird dort als Meldung angezeigt. So findest du heraus, welche externen Quellen du berücksichtigen musst, zum Beispiel ein Analyse-Tool, Schriften oder ein Kartendienst.

Schritt 5: Die Policy verfeinern und scharf schalten

Ergänze nun die Quellen, die du wirklich brauchst, möglichst konkret und nicht mit Platzhaltern. Ein Beispiel für eine Seite mit einem externen Analyse-Skript und einem eingebetteten Kartendienst:

script-src 'self' https://analytics.example.com;
frame-src https://maps.example.com;
connect-src 'self' https://analytics.example.com;

Die MDN Web Docs warnen ausdrücklich vor 'unsafe-inline'. Es erlaubt Inline-Skripte, Inline-Event-Handler wie onclick und javascript:-URLs und nimmt der CSP damit einen grossen Teil ihrer Schutzwirkung. Die empfohlene Alternative ist eine sogenannte strikte CSP mit Nonces oder Hashes:

Content-Security-Policy: script-src 'nonce-ZUFALLSWERT'; object-src 'none'; base-uri 'none'

Der Nonce ist ein Zufallswert, der bei jeder Anfrage neu erzeugt wird und sowohl im Header als auch im script-Tag steht. Er muss unvorhersehbar sein, sonst ist er wertlos. Für statische Seiten sind Hashes der Skriptinhalte oft einfacher. Mit 'strict-dynamic' kannst du ausserdem Skripten, denen du vertraust, erlauben, weitere Skripte nachzuladen. Das vereinfacht die Einbindung von Drittanbietern, birgt aber ein Restrisiko.

Wenn die Konsole im Testmodus über mehrere Tage keine unerwarteten Meldungen mehr zeigt, benenne den Header von Content-Security-Policy-Report-Only in Content-Security-Policy um. Beide Header können übrigens gleichzeitig laufen: Die bewährte Policy erzwingst du, die strengere testest du parallel im Report-Only-Modus.

Typische Fehler beim Setzen von Security Headern

• HSTS zu früh mit preload: Wenn eine Subdomain noch kein HTTPS kann, sperrst du Besucher aus. Teste zuerst mit kurzer Laufzeit.
• CSP ohne Testphase: Plötzlich funktionieren Formulare, Chat-Widgets oder Videos nicht mehr.
• Zu breite Freigaben: Ein Eintrag wie *.beispiel.org kann mehr Quellen öffnen, als dir lieb ist. Erlaube lieber konkrete Hosts.
• Header nur auf der Startseite: Die Header sollten für alle Antworten gelten, auch für Unterseiten, Fehlerseiten und Dateien.
• CSP als einzige Massnahme: Auch mit CSP bleiben saubere Eingabeprüfung und regelmässige Updates Pflicht.

Security Header im Alltag pflegen

Mit der einmaligen Einrichtung ist es nicht getan. Sicherheit ist ein Prozess, und deine Website verändert sich laufend: neue Seiten, neue Formulare, neue Dienste von Drittanbietern. Jedes Mal, wenn du etwas Externes einbindest, muss deine Content Security Policy angepasst werden, sonst blockiert der Browser die neue Funktion. Plane deshalb einen festen Rhythmus ein, zum Beispiel einmal pro Quartal: Header mit curl prüfen, Konsole auf Verstösse durchsehen und nicht mehr genutzte Freigaben entfernen. Je kleiner die Liste der erlaubten Quellen, desto besser ist dein Schutz.

Halte ausserdem fest, wer bei euch für diese Konfiguration verantwortlich ist und wo sie dokumentiert ist. Gerade wenn Hosting, Website und Marketing von verschiedenen Personen betreut werden, geht sonst schnell der Überblick verloren. Eine kurze Textdatei mit den gesetzten Headern, dem Datum der letzten Änderung und den freigegebenen Drittanbietern spart dir im Ernstfall viel Zeit. Und wenn du Security Header setzen willst, ohne selbst am Server zu schrauben, übernehmen wir das gerne für dich, inklusive Test und Dokumentation.

Fazit: Security Header setzen lohnt sich für jedes KMU

Wer Security Header setzt, gewinnt mit wenig Aufwand viel Sicherheit. Starte mit HSTS und den drei einfachen Headern, führe die Content Security Policy über den Report-Only-Modus ein und schärfe sie in Ruhe nach. Prüfe nach jeder Änderung mit curl und im Browser, ob alles wie erwartet funktioniert. Gerade bei Websites mit mehreren eingebundenen Diensten ist es sinnvoll, das Setup einmal professionell aufzusetzen und zu dokumentieren. Welche Möglichkeiten wir dafür haben, siehst du bei unseren Leistungen, oder du nimmst direkt Kontakt mit uns auf.

Häufige Fragen

Machen Security Header meine Website langsamer?

Nein. Die Header sind winzige Textzeilen in der Serverantwort. Du merkst keinen Unterschied bei der Ladezeit.

Kann ich die Content Security Policy auch ohne Servereingriff setzen?

Ja, teilweise. Die CSP lässt sich auch per meta-Element im HTML setzen, allerdings mit eingeschränktem Funktionsumfang. So unterstützt der Report-Only-Modus kein meta-Element. Der HTTP-Header ist die bessere Lösung.

Wie oft sollte ich meine Security Header überprüfen?

Mindestens nach jedem grösseren Umbau deiner Seite und immer dann, wenn du einen neuen externen Dienst einbindest, etwa ein Tracking-Tool, ein Video oder ein Buchungssystem. Ein kurzer Check mit curl dauert nur eine Minute.