HTTP-Sicherheitsheader: welche sinnvoll sind und warum

HTTP-Sicherheitsheader geben dem Browser Regeln für Transport, MIME-Typen, Referrer, Berechtigungen, Isolation und Einbettung vor. Entscheidend ist nicht die Konfigurationsdatei, sondern der Header, der tatsächlich in der HTTP-Antwort ankommt.

HSTS und HTTPS

Strict-Transport-Security weist Browser an, für einen Zeitraum nur HTTPS zu verwenden. Aktiviere HSTS erst, wenn HTTPS auf den betroffenen Hosts zuverlässig funktioniert. Für die Preload-Liste gelten zusätzliche Anforderungen: unter anderem includeSubDomains und ein max-age von mindestens einem Jahr.

MIME-Sniffing verhindern

X-Content-Type-Options: nosniff verhindert, dass Browser bestimmte Inhalte entgegen dem deklarierten MIME-Typ interpretieren. Korrekte Content-Type-Header bleiben trotzdem notwendig.

Referrer-Informationen begrenzen

Referrer-Policy steuert, wie viele URL-Informationen bei Navigationen und Requests weitergegeben werden. Eine passende Richtlinie reduziert unnötige Datenlecks, ohne nützliche Origin-Informationen pauschal zu verlieren.

Browser-Funktionen einschränken

Mit Permissions-Policy lassen sich Funktionen wie Kamera, Mikrofon oder Geolocation begrenzen. Erlaube nur, was die Anwendung wirklich benötigt. COOP, COEP und CORP können zusätzlich helfen, Dokumente und Ressourcen voneinander zu isolieren.

CSP gehört in dieselbe Prüfung

Content Security Policy ist ebenfalls ein Security-Header, ist aber komplex genug für einen eigenen CSP-Leitfaden. Verlasse dich nicht auf veraltete Header als universelle Schutzmaßnahme.

Mit dem Security-Header-Generator kannst du eine Ausgangskonfiguration erstellen. Prüfe anschließend immer die reale Produktionsantwort.