HTTP-Sicherheitsheader: Was Unternehmenswebsites schützen

Eine Website kann aktuell sein, ein gültiges TLS-Zertifikat haben und trotzdem unnötige Angriffsflächen im Browser lassen. HTTP-Sicherheitsheader geben dem Browser zusätzliche Regeln mit: Welche Inhalte eine Seite laden darf, ob eine Verbindung künftig nur per HTTPS erfolgen soll und welche Browser-Funktionen nicht gebraucht werden. Für Unternehmen sind sie deshalb ein sinnvoller Baustein zwischen Hosting, Entwicklung und laufender Wartung.

HTTP-Sicherheitsheader ersetzen keine Updates, keine Rechtekonzepte und keine Prüfung von Erweiterungen. Sie können aber Folgen bestimmter Fehler begrenzen und machen technische Erwartungen nachvollziehbar. Entscheidend ist nicht, möglichst viele Header zu kopieren, sondern sie zum tatsächlichen Website-Setup passend einzuführen und zu testen.

Was HTTP-Sicherheitsheader leisten – und was nicht

HTTP-Header sind Informationen, die ein Server zusammen mit einer Antwort an den Browser liefert. Sicherheitsheader beeinflussen, wie der Browser mit Inhalten und Funktionen auf der Seite umgeht. Das OWASP Secure Headers Project beschreibt sie als eine Möglichkeit, vermeidbare Schwachstellen in modernen Browsern einzuschränken.

Ein Header kann beispielsweise verhindern, dass eine Seite in einem fremden Frame eingebettet wird. Ein anderer begrenzt, von welchen Quellen Skripte, Bilder oder Schriften geladen werden dürfen. Das hilft unter anderem gegen Clickjacking oder dabei, Auswirkungen von Cross-Site-Scripting zu reduzieren.

Die Grenzen sind genauso wichtig: Ein Header repariert keine verwundbare Anwendung, verschlüsselt keine Datenbank und erkennt keine kompromittierten Zugangsdaten. Er ist eine Schutzschicht, nicht der gesamte Sicherheitsplan. Zu einem belastbaren Betrieb gehören weiterhin Updates, Backups, Zugriffsrechte, Monitoring und ein geregelter Umgang mit Störungen. Der Artikel zum Notfallplan bei Website-Ausfällen ordnet diese Betriebsseite ein.

Diese HTTP-Sicherheitsheader sind für Unternehmenswebsites relevant

Die folgende Übersicht ist kein universelles Rezept. Welche Richtlinie passt, hängt von eingebundenen Diensten, Formularen, Analysewerkzeugen, Karten, Videos, Shop-Funktionen und einer möglichen API ab.

Header oder Regel	Aufgabe	Besonderer Prüfpunkt
Content-Security-Policy	Legt erlaubte Quellen für Skripte, Bilder, Schriften und weitere Inhalte fest.	Externe Dienste und Inline-Skripte dürfen nicht versehentlich die Seite brechen.
Strict-Transport-Security	Merkt sich für künftige Aufrufe, dass eine Domain nur über HTTPS erreichbar sein soll.	Erst setzen, wenn HTTPS inklusive benötigter Subdomains stabil funktioniert.
X-Content-Type-Options: nosniff	Verhindert, dass der Browser bestimmte Inhaltstypen errät.	Server muss korrekte MIME-Typen ausliefern.
frame-ancestors in der CSP	Bestimmt, wer die Seite in einem Frame einbetten darf.	Eingebettete Partner- oder Portalansichten vorher prüfen.
Referrer-Policy	Steuert, wie viele Informationen einer Quell-URL an andere Ziele übergeben werden.	Kampagnen- und Login-Flows auf die benötigten Informationen prüfen.
Permissions-Policy	Erlaubt oder sperrt ausgewählte Browser-Funktionen wie Kamera oder Geolocation.	Nur Funktionen begrenzen, deren Nutzung wirklich geklärt ist.

Die Content Security Policy (CSP) braucht besonders viel Sorgfalt. Laut MDN steuert sie, welche Quellen der Browser für eine Seite laden darf, und kann damit gegen Cross-Site-Scripting helfen. Gerade deshalb ist sie kein Einzeiler für die Standardkonfiguration: Ein zu enger Wert kann Cookie-Banner, Formulare, Webfonts, Videos oder Messung blockieren; ein zu weiter Wert bringt kaum zusätzlichen Schutz.

Auch HSTS verlangt eine bewusste Entscheidung. Der Header weist den Browser an, spätere Zugriffe auf die jeweilige Domain ausschließlich über HTTPS zu behandeln. Mit includeSubDomains wird die Regel auf alle Subdomains erweitert. MDN weist ausdrücklich darauf hin, dass dies erst passt, wenn die betroffenen Hosts dauerhaft korrekt per HTTPS erreichbar sind. Alte Test- oder Mail-Subdomains gehören daher vorab auf den Prüfstand.

Erst den Bestand erfassen, dann Richtlinien schreiben

Viele Probleme entstehen nicht durch den Header selbst, sondern durch vergessene Abhängigkeiten. Eine Marketingseite lädt vielleicht lokal gehostete Schriften, ein Kontaktformular bindet reCAPTCHA ein, ein Shop arbeitet mit Zahlungsdienstleistern und ein Kampagnenbereich nutzt ein Tag-Management-System. Jede dieser Quellen muss bei einer restriktiven CSP eingeplant werden.

Vor dem technischen Eingriff sollte das Team deshalb erfassen:

• welche Domains Scripts, Styles, Bilder, Schriften, Frames und API-Aufrufe liefern,
• welche Seiten besondere Funktionen haben, etwa Checkout, Login, Suche oder Bewerbung,
• welche Drittanbieter erst nach Einwilligung geladen werden,
• wo Inline-Skripte, dynamische Styles oder eingebettete Widgets vorkommen,
• welche Subdomains existieren und wie sie HTTPS handhaben,
• wer bei Fehlern eine Einstellung am Server, CDN oder Anwendungs-Deployment zurücknehmen kann.

Diese Liste ist auch für Performance und Datenschutz nützlich: Sie zeigt, welche Dienste eine Seite technisch wirklich braucht. Bei gewachsenen Installationen lohnt sich eine Prüfung im Rahmen von WordPress Support oder Webhosting & WordPress-Hosting, statt Regeln nur im Browser-Plugin zu testen.

Content Security Policy kontrolliert ausrollen

Für CSP empfiehlt sich ein gestufter Ablauf. Zuerst wird beobachtet, welche Ressourcen die Seite tatsächlich lädt. Anschließend wird die Richtlinie in einer Testumgebung mit repräsentativen Seiten ausprobiert. Ein Berichtmodus kann Hinweise liefern, ohne Besucher direkt zu blockieren. Erst wenn die Ausnahmen fachlich verstanden sind, sollte die Schutzwirkung schrittweise aktiviert werden.

Dabei gilt: Eine Ausnahme ist nicht automatisch falsch, aber sie braucht einen Grund. Wird beispielsweise unsafe-inline dauerhaft ergänzt, damit ein einzelnes eingebundenes Script funktioniert, sollte geprüft werden, ob der Dienst anders eingebunden oder das Script mit Nonce beziehungsweise Hash abgesichert werden kann. Die passende technische Lösung hängt von Architektur und Release-Prozess ab.

Für die Abnahme reichen reine Header-Scanner nicht aus. Sie zeigen, ob ein Feld vorhanden ist, aber nicht, ob die Website noch ihren Zweck erfüllt. Testen Sie zumindest:

1. zentrale Inhaltsseiten auf Desktop und Mobilgerät,
2. Kontakt- und Bewerbungsformulare einschließlich Fehlermeldungen und Versand,
3. Consent-Zustände vor Einwilligung, nach Einwilligung und nach Widerruf,
4. eingebettete Inhalte wie Karten, Videos oder Terminbuchung,
5. Login, Suche, Warenkorb und Checkout, falls vorhanden,
6. Kampagnen-Landingpages und Parameter in Weiterleitungen,
7. Browser-Konsole und Netzwerkanfragen auf blockierte Ressourcen.

Ein gefundener Konflikt ist ein Abnahmesignal, kein Anlass, die Richtlinie pauschal zu lockern. Zuerst muss klar sein, ob die Ressource fachlich nötig ist, korrekt konfiguriert werden kann oder besser verschwindet.

Typische Fehlannahmen vermeiden

Eine häufige Fehlannahme lautet: „Unser CDN setzt das schon.“ Manche Hoster oder CDNs liefern Basisschutz, aber die tatsächlichen Header können pro Domain, Pfad, Cache-Regel oder Anwendung unterschiedlich sein. Deshalb gehören die Antworten zentraler URLs in die technische Abnahme.

Ebenso problematisch ist es, Header nur für die Startseite zu prüfen. Gerade Formulare, Downloads, Kundenbereiche, Sprachversionen und Fehlerseiten haben oft andere technische Pfade. Eine Richtlinie, die im normalen Browserfenster gut aussieht, kann dort unbemerkt Funktionen verhindern.

Bei der Permissions Policy ist Zurückhaltung sinnvoll. Der Header kann Browser-Funktionen für das Dokument und eingebettete Frames erlauben oder untersagen. Laut MDN ist die Unterstützung einzelner Funktionen nicht in allen Browsern gleich. Die Policy sollte daher an konkreten Anforderungen ausgerichtet und vor allem bei eingebetteten Anwendungen getestet werden.

Eine pragmatische Reihenfolge für Unternehmen

Wer bisher keine dokumentierte Header-Strategie hat, muss nicht alles in einem Release lösen. Dieser Ablauf reduziert Risiko und schafft eine überprüfbare Grundlage:

1. Bestehende Header für die wichtigsten Seitentypen dokumentieren.
2. HTTPS, Redirects und Subdomains auf offensichtliche Sonderfälle prüfen.
3. Niedrigriskante Basisregeln mit dem realen Hosting-Setup abstimmen.
4. Drittanbieter und dynamische Seiten für eine CSP erfassen.
5. CSP zunächst beobachtend testen und Befunde priorisieren.
6. Staging- und Live-Abnahme mit einem Rückweg im Deployment planen.
7. Nach Änderungen erneut kontrollieren und die Regeln bei neuen Diensten fortschreiben.

HTTP-Sicherheitsheader wirken am besten als Teil eines wiederholbaren Betriebsprozesses. Sie machen die Website nicht unangreifbar, erschweren aber vermeidbare Browser-Angriffe und zwingen zu einer hilfreichen Frage: Welche externen Funktionen darf diese Seite tatsächlich laden und ausführen?

Fazit: Sicherheit braucht passende Regeln und einen getesteten Rückweg

Für Unternehmenswebsites sind Sicherheitsheader kein kosmetischer Scan-Punkt. Sie verbinden Serverkonfiguration, externe Dienste und die reale Nutzung einer Seite. Beginnen Sie mit einer Bestandsaufnahme, führen Sie Richtlinien kontrolliert ein und testen Sie die geschäftskritischen Wege vor dem Livegang. So wird aus einer langen Headerliste eine nachvollziehbare technische Schutzschicht.