Security Header: Der unterschätzte Website-Check für Browser-Schutz

Viele Website-Projekte prüfen Sicherheit erst, wenn etwas sichtbar kaputt ist: Login funktioniert nicht, Formular-Spam explodiert, ein Plugin hat eine Lücke oder der Kunde fragt nach einem Security-Scan. Dabei gibt es eine unspektakuläre Basis, die viel früher auffällt: HTTP-Sicherheitsheader.

Security Header sind keine Firewall und ersetzen keinen sauberen Code. Aber sie geben dem Browser klare Regeln: Welche Quellen dürfen Skripte laden? Soll die Website dauerhaft nur per HTTPS geöffnet werden? Wie viel Referrer-Information geht an externe Dienste? Darf die Seite in fremde Frames eingebettet werden?

OWASP beschreibt HTTP Header als einfache, aber wirksame Verstärkung für Web-Sicherheit. MDN dokumentiert unter anderem, dass Content Security Policy Ressourcen einschränken und gegen Cross-Site-Scripting helfen kann, HSTS künftige Zugriffe auf HTTPS erzwingt und Referrer-Policy steuert, wie viel Herkunftsinformation bei Requests mitgesendet wird.

Warum Header in Website-Audits gehören

Für kleine Websites, WordPress-Projekte, SaaS-Landingpages und Agenturprojekte sind Header oft zwischen Hosting, CMS, CDN, Framework und Reverse Proxy verteilt. Genau dort entstehen Lücken:

• Der CDN setzt HSTS, aber die Staging-Domain bricht.
• Das Framework setzt Standardheader, aber der Reverse Proxy überschreibt sie.
• Ein Cookie- oder Chat-Widget braucht externe Skripte und die CSP wird aus Bequemlichkeit zu weit geöffnet.
• Referrer-Policy fehlt und Kampagnen-URLs mit Parametern werden unnötig an Dritte weitergegeben.
• X-Powered-By verrät unnötig Framework-Details.
• Alte Header wie X-XSS-Protection werden blind kopiert, obwohl moderne Empfehlungen eher CSP bevorzugen.

Das Problem ist selten ein einzelner fehlender Header. Das Problem ist, dass niemand weiß, welche Schicht die Header kontrolliert.

Die praktische Mindestprüfung

Ein Website-Check sollte nicht einfach nur ein Online-Scanner-Ergebnis kopieren. Besser ist ein kleiner, nachvollziehbarer Audit:

1. Produktionsdomain testen: Welche Header werden auf Startseite, Unterseiten, Login, Formularen und Checkout ausgeliefert?
2. Redirect-Kette prüfen: Kommt HTTP sauber auf HTTPS? Werden Header erst nach dem finalen Redirect gesetzt?
3. CSP realistisch bewerten: Gibt es eine Policy oder nur unsafe-inline und Wildcards?
4. HSTS vorsichtig einführen: Erst kurze Laufzeit testen, dann längere Werte und Subdomains nur, wenn Zertifikate und Subdomains wirklich unter Kontrolle sind.
5. Referrer-Policy setzen: Für viele Websites ist strict-origin-when-cross-origin ein sinnvoller Ausgangspunkt.
6. MIME-Sniffing verhindern: X-Content-Type-Options: nosniff setzen und Content-Types korrekt ausliefern.
7. Embedding regeln: frame-ancestors in CSP nutzen, wenn Seiten nicht fremd eingebettet werden sollen.
8. Caching sensibler Seiten prüfen: Login, Konto, Checkout und interne Bereiche brauchen andere Regeln als öffentliche Assets.

CSP ohne Selbstzerstörung

Content Security Policy ist mächtig, aber auch der Header, mit dem Teams sich am schnellsten selbst ins Knie schießen. Eine zu harte Policy kann Formulare, Zahlungen, Tracking, Videos oder Consent-Banner brechen. Eine zu weiche Policy sieht gut aus, schützt aber kaum.

Der bessere Weg:

• Erst Inventar der externen Skripte, Styles, Bilder, Frames und APIs erstellen.
• Dann eine Content-Security-Policy-Report-Only testen.
• Verstöße sammeln und bewusst entscheiden, was wirklich erlaubt sein muss.
• Danach schrittweise erzwingen.
• Jede neue Drittanbieter-Integration als CSP-Änderung behandeln.

Gerade für Agenturen ist das ein guter Übergabepunkt: Wenn der Kunde später ein neues Tracking-Pixel einbaut, sollte klar sein, dass dies nicht nur Marketing ist, sondern auch Security-Konfiguration verändert.

Header als Wartungsaufgabe

Security Header sind kein Einmal-Ticket. Sie ändern sich mit Hosting, CDN, Framework, Plugins und Drittanbieter-Tools. Deshalb gehören sie in eine Wartungsroutine:

• Nach Relaunch oder Hostingwechsel erneut prüfen.
• Nach CDN- oder Proxy-Änderungen Header vergleichen.
• Nach neuen Formular-, Payment-, Chat- oder Tracking-Tools CSP testen.
• Einmal pro Quartal einen Header-Scan durchführen.
• Header-Konfiguration im Repository oder Betriebshandbuch dokumentieren.

Fazit

HTTP-Sicherheitsheader sind langweilig im besten Sinn. Sie machen keine schöne Landingpage und verkaufen kein Produkt. Aber sie reduzieren unnötige Angriffsfläche, schützen Nutzer:innen und zeigen, ob ein Website-Team seine Infrastruktur im Griff hat. Ein guter Website-Check sollte deshalb nicht nur Plugins, Performance und Cookie-Banner prüfen, sondern auch die Header, die der Browser wirklich sieht.

Quellen

• OWASP Cheat Sheet Series: HTTP Security Response Headers
• MDN: Content-Security-Policy (CSP) header
• MDN: Strict-Transport-Security header
• MDN: Referrer-Policy header

Hinweis: Dieser Beitrag ist eine technische Einordnung und keine Rechtsberatung.