HTTP-Security-Header erklärt: HSTS, CSP und mehr

Was Security-Header sind

Jede HTTP-Antwort beginnt mit Headern: Paaren aus Name und Wert wie Content-Type: text/html. Einige davon ändern, wie der Browser die Seite behandelt. Sie kosten nichts, gelten für jeden Besucher und werden auf dem Server, der Hosting-Plattform oder einem Content Delivery Network gesetzt, nicht im HTML der Seite.

IPNixa setzt seine eigenen Header in einer _headers-Datei, die Cloudflare mit jeder Seite ausliefert. Die Prüfung auf dieser Website ruft die eingegebene Adresse von unserem Server aus ab, folgt bis zu drei Weiterleitungen und liest die Header der endgültigen Antwort.

Die sechs wichtigsten Header

Diese Header bewertet die Prüfung. Die gezeigten Werte sind verbreitete, sichere Ausgangspunkte; sie sollten an die Anforderungen der eigenen Website angepasst werden.

Wie die IPNixa-Prüfung jeden Header bewertet

Jeder Header erhält einen von drei Zuständen: „vorhanden“, „prüfen“ oder „fehlt“. „Prüfen“ bedeutet, dass der Header existiert, sein Wert aber die jeweilige Regel unten nicht erfüllt. Das ist ein Hinweis, genauer hinzusehen, keine Sicherheitsbewertung.

• HSTS gilt als vorhanden, wenn der Header genau einmal mit einem max-age von mindestens 15552000 Sekunden (180 Tage) erscheint. Ein kürzeres max-age oder der Wert 0 wird mit „prüfen“ markiert.
• CSP gilt als vorhanden, wenn sie Skripte über script-src oder default-src steuert und nirgends in der Richtlinie 'unsafe-inline', 'unsafe-eval' oder ein einzelnes * enthält. Eine Report-Only-Richtlinie gilt als fehlend, weil sie nichts blockiert.
• Der Frame-Schutz gilt als vorhanden, wenn eine frame-ancestors-Direktive auf 'none', 'self' oder exakte Adressen beschränkt ist oder X-Frame-Options auf DENY oder SAMEORIGIN steht.
• X-Content-Type-Options gilt nur mit dem Wert nosniff als vorhanden.
• Referrer-Policy gilt als vorhanden, wenn der letzte Wert no-referrer, same-origin, strict-origin oder strict-origin-when-cross-origin ist. Browser verwenden den letzten Wert, den sie verstehen, daher zählt bei einer Liste der letzte Eintrag.
• Permissions-Policy gilt als vorhanden, sobald der Header überhaupt gesendet wird, denn die passende Liste von Funktionen hängt von der Website ab.

Was echte Websites senden: eine Stichprobe

Am 2. November 2026 haben wir fünf Startseiten mit demselben User-Agent abgerufen, den die Prüfung verwendet, und die Antworten nach den Bewertungsregeln von IPNixa ausgewertet. Header ändern sich häufig, daher ist das nur eine Momentaufnahme.

Stichprobe einordnen: „prüfen“ bedeutet keine Schwäche

Die Richtlinie von GitHub beschränkt Skripte auf den eigenen Asset-Host und bestimmte Hashes und ist damit streng. Sie wird nur deshalb mit „prüfen“ markiert, weil ihr style-src 'unsafe-inline' erlaubt und die Regel nach diesem Schlüsselwort in der gesamten Richtlinie sucht. Inline-Styles sind ein deutlich kleineres Risiko als Inline-Skripte, daher ist das ein bewusster Kompromiss und keine Lücke.

Unsere eigene Website wird aus einem anderen Grund mit „prüfen“ markiert: Ihre Richtlinie enthält nur frame-ancestors 'none'. Das verhindert das Einbetten, schränkt aber keine Skripte ein. Wir geben das Ergebnis hier unverändert wieder.

Die Startseite von Google sendet ihre Skriptrichtlinie als Content-Security-Policy-Report-Only, die Verstöße meldet, ohne sie zu blockieren, und schickte in dieser Antwort kein HSTS; große Websites können HTTPS auch auf anderem Weg durchsetzen, etwa über Preload-Listen der Browser. Das Portal von Wikipedia sendet ein sehr langes HSTS-max-age und auf dieser Seite sonst wenig. Nichts davon sagt aus, ob diese Websites insgesamt sicher sind; es zeigt nur, welche Schutzmaßnahmen im Browser jede Antwort anfordert.

Header auf der eigenen Website hinzufügen

Header einzeln hinzufügen, die Website neu laden und prüfen, ob Seiten, Logins, eingebettete Videos und Zahlungsformulare noch funktionieren, bevor der nächste Header folgt.

1. Mit den risikoarmen Headern beginnen: X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin und X-Frame-Options: DENY, sofern die Seiten nicht von einer anderen Website eingebettet werden müssen.
2. HSTS mit einem kurzen max-age wie 300 hinzufügen, prüfen, ob jede Subdomain per HTTPS funktioniert, und den Wert dann auf 31536000 erhöhen. includeSubDomains nur ergänzen, wenn alle Subdomains HTTPS unterstützen.
3. Eine Content-Security-Policy schreiben und zunächst als Content-Security-Policy-Report-Only senden. Verstoßberichte sammeln oder die Browserkonsole beobachten, legitime Quellen korrigieren oder zulassen und dann auf den durchsetzenden Header umstellen.
4. Permissions-Policy hinzufügen und darin die leistungsstarken Funktionen aufführen, die nicht genutzt werden, zum Beispiel camera=(), microphone=(), geolocation=().
5. Unter nginx add_header mit dem Flag always verwenden, unter Apache Header always set, bei statischem Hosting oder einem CDN die Header-Datei oder die Regeln für Antwortheader der Plattform.
6. Die Header-Prüfung von IPNixa erneut ausführen. Für jeden fehlenden Header zeigt sie eine kopierfertige Zeile für nginx, Apache oder eine _headers-Datei.

HSTS-Preload und andere Fallstricke

HSTS-Preload-Listen sind in Browser integriert, sodass schon der allererste Aufruf HTTPS nutzt. Für die Aufnahme einer Domain sind ein max-age von mindestens einem Jahr, includeSubDomains und die Anweisung preload erforderlich, und bis eine Entfernung bei den Nutzern ankommt, vergehen Monate. Nur eintragen lassen, wenn jede Subdomain, auch interne, dauerhaft HTTPS nutzt.

X-XSS-Protection ist veraltet; moderne Browser ignorieren den Header, und eine CSP ersetzt ihn. Die Header für Cross-Origin-Isolation (Cross-Origin-Opener-Policy, Cross-Origin-Embedder-Policy und Cross-Origin-Resource-Policy) bewertet die Prüfung nicht, weil sie nur für Websites nötig sind, die Funktionen wie gemeinsamen Speicher nutzen, und ihre Aktivierung eingebettete Inhalte von Drittanbietern blockieren kann.