Website prüfen

Security-Header erklärt: HSTS, CSP und Co. verständlich

Veröffentlicht am · Stand: · Lesezeit ca. 7 Minuten

Wenn ein Browser eine Website lädt, schickt der Server nicht nur den Inhalt, sondern auch Kopfzeilen, die sogenannten HTTP-Header. Einige davon geben dem Browser Sicherheitsregeln vor: Nur verschlüsselt verbinden, Dateitypen nicht erraten, keine fremden Skripte laden. Diese Security-Header verursachen keine Lizenzkosten und erschweren typische Angriffswege. Viele kleine Websites setzen sie trotzdem nicht. Dieser Ratgeber erklärt die wichtigsten, zeigt Beispiele und sagt, was Sie bei Baukasten und Hostern beachten müssen.

Warum Security-Header?

Header sind eine zusätzliche Schutzschicht. Sie reparieren keinen fehlerhaften Code, begrenzen aber den Schaden, wenn etwas schiefgeht: wenn jemand versucht, Schadcode in eine Seite einzuschleusen, Ihre Seite unsichtbar in einen fremden Rahmen zu legen oder Besucher auf eine unverschlüsselte Verbindung zu lenken. Rechtlich verlangen Art. 32 DSGVO von Verantwortlichen angemessene technische und organisatorische Maßnahmen und § 19 Abs. 4 TDDDG von Anbietern geschäftsmäßiger digitaler Dienste Schutzvorkehrungen nach dem Stand der Technik, soweit technisch möglich und wirtschaftlich zumutbar. Einzelne Header schreiben beide Normen nicht vor. Ob eine fehlende Header-Konfiguration im Einzelfall ein Verstoß ist, hängt vom Risiko und den Umständen ab. Das ist eine Frage für die Fachperson, keine Pauschalaussage.

Strict-Transport-Security (HSTS)

HSTS sagt dem Browser: „Verbinde dich mit dieser Domain in Zukunft nur noch per HTTPS.“ Hat der Browser den Header einmal erhalten, ruft er die Domain bis zum Ablauf der Laufzeit nicht mehr unverschlüsselt über HTTP auf, auch wenn jemand http:// eintippt. Das erschwert es Angreifern, etwa in öffentlichen WLANs, Verbindungen umzulenken. Den allerersten Besuch schützt HSTS nur, wenn die Domain in der Preload-Liste der Browser steht.

Strict-Transport-Security: max-age=31536000

31536000 Sekunden entsprechen einem Jahr; das ist ein üblicher Zielwert. Beachten Sie: includeSubDomains betrifft auch alle Unterdomains, die dann ebenfalls per HTTPS erreichbar sein müssen. Die Option preload ist Voraussetzung, um die Domain über hstspreload.org in die fest eingebaute Liste der Browser eintragen zu lassen. Ein solcher Eintrag lässt sich nur mühsam und mit monatelanger Verzögerung rückgängig machen. Starten Sie deshalb mit einer kurzen Laufzeit (zum Beispiel einem Tag), prüfen Sie, ob alles funktioniert, und erhöhen Sie dann.

HSTS setzt voraus, dass Ihre Website sauber über HTTPS läuft: gültiges Zertifikat, Weiterleitung von HTTP auf HTTPS und keine eingebundenen Inhalte über unverschlüsselte Adressen (Mixed Content).

X-Content-Type-Options

Browser versuchen manchmal, den Typ einer Datei zu „erraten“. Das kann dazu führen, dass eine hochgeladene Datei als Skript ausgeführt wird. Mit nosniff verbieten Sie das:

X-Content-Type-Options: nosniff

In aller Regel spricht nichts dagegen, ihn zu setzen. Voraussetzung ist, dass Ihr Server jede Datei mit dem richtigen Inhaltstyp ausliefert.

Content-Security-Policy (CSP)

Die CSP ist der mächtigste und zugleich anspruchsvollste Header. Sie legt fest, von wo eine Seite Skripte, Stile, Bilder, Schriften und andere Inhalte laden darf. Lädt jemand eingeschleusten Code von einer fremden Adresse nach, blockiert der Browser das. Ein einfaches Beispiel für eine Website, die alles von der eigenen Domain lädt:

Content-Security-Policy: default-src 'self'; img-src 'self' data:; frame-ancestors 'none'

In der Praxis scheitert die CSP oft an Inline-Skripten, Inline-Stilen und Diensten von Drittanbietern wie Karten, Videos oder Buchungstools. Gehen Sie schrittweise vor:

  1. Setzen Sie zuerst Content-Security-Policy-Report-Only. Der Browser meldet Verstöße, blockiert aber nichts.
  2. Beheben Sie die Meldungen: Skripte auslagern, bei Bedarf mit Hash oder Nonce erlauben, unnötige Drittanbieter entfernen.
  3. Wechseln Sie erst dann auf den scharfen Header.

Ein Nebeneffekt: Eine strenge CSP deckt auch versehentlich eingebundene Fremddienste auf, etwa Schriften von Google-Servern. Mehr zu diesem Thema im Ratgeber Google Fonts und DSGVO.

Clickjacking-Schutz: X-Frame-Options und frame-ancestors

Beim Clickjacking legt ein Angreifer Ihre Seite unsichtbar in einen eigenen Rahmen und verleitet Nutzer zu Klicks. Dagegen hilft ein Verbot, die Seite einzubetten:

X-Frame-Options: SAMEORIGIN
Content-Security-Policy: frame-ancestors 'self'

Der moderne Weg ist frame-ancestors in der CSP, X-Frame-Options ist die ältere, aber noch weit verbreitete Variante. Wer beides setzt, deckt auch ältere Browser ab. Betten Sie Ihre Seiten selbst irgendwo ein, passen Sie die Werte entsprechend an.

Referrer-Policy und Permissions-Policy

Die Referrer-Policy steuert, wie viel von Ihrer Adresse an andere Websites übermittelt wird, wenn Besucher einen Link anklicken. Ein guter Standard ist:

Referrer-Policy: strict-origin-when-cross-origin

Dann sehen fremde Seiten nur die Domain, nicht den vollständigen Pfad mit möglichen Parametern. Moderne Browser verwenden diesen Wert zwar bereits als Voreinstellung, ausdrücklich gesetzt ist er aber verlässlicher und wird von Prüfwerkzeugen erkannt.

Die Permissions-Policy schaltet Browserfunktionen ab, die Ihre Seite nicht braucht:

Permissions-Policy: camera=(), microphone=(), geolocation=()

So kann auch eingebetteter oder eingeschleuster Code diese Funktionen nicht anfordern.

Was Sie nicht mehr brauchen

Der Header X-XSS-Protection gilt als veraltet. Moderne Browser ignorieren ihn, und in manchen älteren Versionen konnte er selbst Probleme verursachen. Wenn Sie ihn überhaupt setzen, dann mit dem Wert 0. Verlassen Sie sich stattdessen auf eine CSP und sauberen Code.

So setzen Sie die Header

Wo Sie Header einstellen, hängt vom Hosting ab.

  • Eigener Server (nginx): add_header X-Content-Type-Options "nosniff" always; im Server-Block.
  • Apache: Header always set X-Content-Type-Options "nosniff" in der Konfiguration oder in der .htaccess, sofern das Modul mod_headers aktiv ist.
  • Cloudflare und ähnliche Dienste: Bei Cloudflare lassen sich Antwort-Header über Transform Rules („Modify Response Header“) setzen, ohne den Server anzufassen.
  • WordPress: Per Server-Konfiguration oder Plugin. Prüfen Sie nach der Aktivierung das Ergebnis, denn Plugins decken nicht jede Seite und jede Datei ab.
  • Baukästen und Shopsysteme: Oft ist kein Zugriff auf die Header möglich. Fragen Sie den Anbieter oder schalten Sie einen Dienst wie Cloudflare davor.
  • Hoster ohne Konfigurationszugriff: Manche Plattformen, etwa GitHub Pages, erlauben keine eigenen Header. Ein <meta http-equiv>-Tag kann zumindest eine CSP setzen, aber weder HSTS noch frame-ancestors.

Wenn Sie das nicht selbst umsetzen möchten: Die Konfiguration relevanter Security-Header gehört zum möglichen Umfang des Fix-Pakets (ab 299 €); steht nur dieser eine Punkt an, passt der Einzel-Fix für 99 €. Grenzen, etwa bei Shopify oder Hostern ohne Zugriff, nennen wir vorab.

So prüfen Sie Ihre Header

  1. Im Browser: Entwicklerwerkzeuge öffnen (F12), Reiter „Netzwerk“, Seite neu laden, die erste Anfrage anklicken und die Antwort-Header ansehen.
  2. Auf der Kommandozeile: curl -I https://ihre-domain.de zeigt die Header der Startseite.
  3. Mit dem Sicherheits-Check: Der kostenlose Check für Security-Header prüft HTTPS, Weiterleitung, HSTS, Security-Header und Mixed Content und erklärt, was fehlt.
  4. Regelmäßig: Nach Updates und Hosting-Wechseln können Header verschwinden. Das Monitoring (29 €/Monat) prüft jede Woche.

Häufige Fragen

Welche Security-Header sind am wichtigsten?

Für den Einstieg lohnen sich Strict-Transport-Security, X-Content-Type-Options, Referrer-Policy und ein Schutz vor Einbettung (frame-ancestors oder X-Frame-Options). Die Content-Security-Policy bringt am meisten, braucht aber auch die meiste Vorbereitung.

Kann ein falscher Security-Header meine Website kaputt machen?

Ja, vor allem eine zu strenge Content-Security-Policy kann Skripte, Schriften oder Karten blockieren, und HSTS wirkt langfristig im Browser. Testen Sie schrittweise, nutzen Sie zuerst den Report-Only-Modus und beginnen Sie bei HSTS mit einer kurzen Laufzeit.

Reichen Security-Header für eine sichere Website?

Nein. Sie sind eine Schutzschicht, ersetzen aber keine Updates, sicheren Passwörter und sauberen Programmcode. Auch ein Check mit gutem Ergebnis ist keine Zusicherung der Sicherheit.

Hinweis: Dieser Ratgeber gibt den Stand zum Veröffentlichungsdatum nach unserem Verständnis wieder und ist eine allgemeine technische Information, keine Rechts- oder Sicherheitsberatung. Technische Hintergründe zu den einzelnen Headern beschreibt zum Beispiel die MDN-Dokumentation zu HTTP-Headern; zur HSTS-Preload-Liste hstspreload.org.

Security-Header jetzt prüfen

Weiterlesen im Ratgeber

Alle Themen im Ratgeber, die Prüfbereiche unter Website-Check.