Die 10 häufigsten Fehler bei Sicherheits-Headern (und wie man sie behebt)

HTTP-Antwort-Header sind jene seltene Sicherheitsmaßnahme, die ein paar Zeilen Konfiguration kostet und jeden Besucher sofort schützt. Genau deshalb ist es so verbreitet, sie falsch zu machen: leicht zu kopieren, schwer zu testen. Das sind die zehn Probleme, die in Scan-Ergebnissen immer wieder auftauchen.

1. Kein HSTS (oder HSTS ohne den Preload-Pfad)

Ohne Strict-Transport-Security kann eine einzige Klartext-Anfrage vor der HTTPS-Weiterleitung abgefangen werden. Setzen Sie ein langes max-age und beziehen Sie Subdomains ein:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Fügen Sie preload erst hinzu, wenn jede Subdomain ausschließlich HTTPS ist — es lässt sich nur schwer schnell rückgängig machen.

2. Eine Content-Security-Policy, die unsafe-inline erlaubt

script-src 'unsafe-inline' öffnet genau das XSS-Loch wieder, das CSP schließen soll. Wechseln Sie zu Nonces oder Hashes:

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-{random}'; object-src 'none'; base-uri 'self'

3. CSP für immer im Report-only-Modus ausliefern

Content-Security-Policy-Report-Only ist für die Einführungsphase. Viele Sites lassen es monatelang stehen, sammeln Berichte und erzwingen nichts. Finden Sie mit Report-only Verstöße und wechseln Sie zum erzwingenden Header, sobald Ruhe eingekehrt ist.

4. X-Frame-Options statt frame-ancestors

X-Frame-Options ist veraltet und kann keine Erlaubnisliste ausdrücken. Bevorzugen Sie die CSP-Direktive, die moderne Browser beachten:

Content-Security-Policy: frame-ancestors 'self'

5. Fehlendes X-Content-Type-Options

Ohne X-Content-Type-Options: nosniff kann ein Browser eine Antwort per MIME-Sniffing deuten und etwas ausführen, das Sie als Text ausgeliefert haben. Ein einzelner Header ohne Nachteil — immer setzen.

6. Eine gefährliche oder fehlende Referrer-Policy

Die Voreinstellung gibt vollständige URLs (inklusive Tokens in Query-Strings) an Dritte weiter. Eine sichere, breit kompatible Wahl:

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

7. Permissions-Policy auf dem Browser-Standard belassen

Wenn Ihre App Kamera, Mikrofon oder Standort nicht nutzt, sagen Sie es ausdrücklich, damit ein kompromittiertes Skript es auch nicht kann:

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

8. Header auf HTML setzen, aber nicht auf der API

Von einem Frontend-Framework gesetzte Header übersehen oft API-Routen, Weiterleitungen und Fehlerseiten. Scanner testen diese Pfade direkt. Setzen Sie Sicherheits-Header am Rand — Reverse-Proxy, CDN oder Plattform-Middleware —, damit die Abdeckung einheitlich ist.

9. Widersprüchliche Header aus mehreren Schichten

Wenn App und CDN beide Content-Security-Policy setzen, sieht der Browser womöglich zwei Header und wendet die *Schnittmenge* an, was Funktionen still bricht. Legen Sie eine maßgebliche Schicht fest und entfernen Sie die Duplikate.

10. Sensible Antworten cachen

Authentifizierte Seiten und API-Antworten mit personenbezogenen Daten dürfen von gemeinsam genutzten Proxys nicht zwischengespeichert werden:

Cache-Control: no-store

Mit einem erneuten Scan bestätigen

Header wirken zusammen, also ändern Sie sie in kleinen Chargen und scannen Sie nach jeder erneut. Wenn Sie neu im Lesen der Ergebnisse sind, beginnen Sie mit So lesen Sie einen Website-Sicherheitsbericht; zur Transportschicht unter diesen Headern siehe SSL/TLS-Fehlkonfigurationen, die Ihre Site gefährden. Die vollständige Header-Prüfung läuft bei jedem Scan — siehe alle Prüfungen auf der Funktionsseite.