Security-Header
Security-Header sind HTTP-Antwort-Köpfe, mit denen ein Server dem Browser verbindliche Sicherheits-Regeln vorgibt – etwa welche Skripte laden dürfen oder ob die Seite in einen Rahmen einer anderen Seite eingebettet werden darf.
Security-Header sind eine der wirkungsvollsten und gleichzeitig günstigsten Sicherheits-Maßnahmen für Websites. Einmal sauber konfiguriert blockieren sie ganze Klassen von Angriffen, ohne dass eine Zeile Anwendungs-Code geändert werden muss.
In einfachen Worten
Jede Antwort eines Servers enthält unsichtbare Metadaten – die HTTP-Header. Security-Header sind eine Untergruppe davon und wirken wie verbindliche Hausregeln, die dem Browser mitgeteilt werden: „Erlaube nur Skripte von dieser Quelle", „Erlaube keine Einbettung in fremde Rahmen", „Gib bei Verlinkungen keine sensiblen Daten weiter". Sauber gesetzt blockieren sie ganze Angriffs-Klassen wie Cross-Site-Scripting, Clickjacking und MIME-Sniffing, ohne dass eine Zeile Anwendungs-Code angepasst werden muss. Die wichtigsten Header in einer modernen Konfiguration sind: Content-Security-Policy (steuert, welche Skript- und Stil-Quellen erlaubt sind), X-Frame-Options (steuert die Rahmen-Einbettung), X-Content-Type-Options (verhindert MIME-Sniffing), Referrer-Policy (steuert die Weitergabe der Herkunfts-Adresse) Permissions-Policy (blockiert nicht benötigte Browser-Schnittstellen wie Kamera oder Mikrofon) und Strict-Transport-Security (HSTS, erzwingt die dauerhaft verschlüsselte Auslieferung).
Wozu brauche ich das?
Pflicht für jede produktive Website mit Anmeldung, Bezahl-Funktion oder Verarbeitung personenbezogener Daten nach DSGVO. Auch für reine Inhalts-Websites ein einfacher Sicherheits-Gewinn. Audits, Penetrations-Tests und Datenschutz-Prüfungen prüfen Security-Header als Standard-Element – fehlen sie, gibt es Punkt-Abzüge oder Beanstandungen.
Beispiel aus der Praxis
Bei einem Sicherheits-Audit einer typischen Mittelstands-Website – etwa einer Praxisgemeinschaft mit Online-Termin-Buchung – findet sich häufig: keine Security-Header gesetzt. Mit der Einrichtung von Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy und Permissions-Policy verbessert sich die Bewertung bei einem Header-Audit-Werkzeug deutlich. Der Aufwand liegt bei wenigen Stunden Konfiguration auf dem Webserver, der die Seite ohnehin über HTTPS ausliefert – wirksam ohne eine Zeile Anwendungs-Code. Konkreter Effekt: Angriffs-Klassen wie Clickjacking durch Rahmen-Einbettung sind anschließend technisch ausgeschlossen.
Wirtschaftlicher Nutzen
Security-Header kosten keine Lizenz, keine Hardware und keine wiederkehrenden Gebühren – nur einmalig wenige Stunden Konfiguration. Der wirtschaftliche Wert besteht in der dokumentierten Sorgfalts-Pflicht im Schadens-Fall, einer deutlich reduzierten Angriffs-Fläche gegen Cross-Site-Scripting, Clickjacking und MIME-Sniffing sowie besseren Bewertungen bei Datenschutz- und Sicherheits-Audits. Für Branchen mit erhöhten Schutz-Anforderungen (Gesundheit, Recht, Finanzen) sind sie faktisch Pflicht.
Typische Fehler
- Content-Security-Policy zu streng konfiguriert – eigene Skripte oder Drittanbieter-Werkzeuge brechen über Nacht.
- Content-Security-Policy nur per Meta-Tag statt per HTTP-Header gesetzt – die Schutz-Wirkung ist dann deutlich schwächer.
- X-Frame-Options nicht gesetzt – fremde Seiten können die eigene Website in einen Rahmen einbetten und visuell manipulieren.
- Header einmal gesetzt, aber nie geprüft – typische Konfigurations-Fehler bleiben über Jahre unentdeckt.
- Nach dem Einbinden neuer Drittanbieter-Werkzeuge die Content-Security-Policy nicht angepasst – die neuen Skripte werden blockiert oder die Policy versagt unbemerkt.
Worauf achten?
- Regelmäßig mit einem Header-Audit-Werkzeug die aktuelle Konfiguration bewerten lassen.
- Content-Security-Policy zuerst im Report-Only-Modus betreiben, um Fehl-Alarme vor dem Scharf-Stellen zu finden.
- Permissions-Policy einsetzen, um nicht benötigte Browser-Schnittstellen (Kamera, Mikrofon, Standort) explizit zu blockieren.
- Nach Aktualisierungen externer Dienste die Content-Security-Policy gegenprüfen – neue Skript-Quellen brechen sonst.
- Header zentral im Vermittlungsserver oder im Auslieferungs-Netz setzen, nicht in jeder Anwendung einzeln.
Häufig gestellte Fragen
Was sind Security-Header?
HTTP-Antwort-Köpfe, mit denen ein Server dem Browser verbindliche Sicherheits-Regeln vorgibt – etwa welche Skript-Quellen erlaubt sind, ob die Seite in einen fremden Rahmen eingebettet werden darf oder welche Browser-Schnittstellen aktiv sein dürfen.
Welche Header sind besonders wichtig?
Content-Security-Policy (Skript- und Stil-Quellen), X-Frame-Options (Rahmen-Einbettung), X-Content-Type-Options (MIME-Sniffing), Referrer-Policy (Herkunfts-Weitergabe) und Permissions-Policy (Browser-Schnittstellen). Diese fünf decken die wichtigsten Angriffs-Klassen ab.
Was ist eine Content-Security-Policy?
Eine Regel-Sammlung, die definiert, aus welchen Quellen ein Browser Skripte, Stylesheets, Bilder oder Schriftarten laden darf. Sie ist die wirksamste Einzelmaßnahme gegen Cross-Site-Scripting-Angriffe.
Was bedeutet Report-Only-Modus?
Ein Test-Modus, in dem die Content-Security-Policy aktiv ist, aber Verstöße nur protokolliert statt blockiert. So lassen sich Fehl-Alarme erkennen und korrigieren, bevor die Policy scharf gestellt wird.
Welcher Aufwand entsteht?
Eine erste Einrichtung erfordert wenige Stunden Konfiguration im Webserver oder Vermittlungsserver. Anschließend sollte die Konfiguration bei jedem Einbinden neuer Drittanbieter-Werkzeuge gegengeprüft werden – die Pflege ist überschaubar.