Security Header Check für HTTP Security Header, CSP und HSTS
Prüft wichtige HTTP Security Header einer URL: Strict-Transport-Security, Content-Security-Policy, X-Frame-Options, Referrer-Policy, Permissions-Policy und weitere.
- HSTS / Strict-Transport-Security
- Content-Security-Policy (CSP)
- X-Frame-Options
- Referrer-Policy
- Permissions-Policy
- X-Content-Type-Options
- Cross-Origin-* Header
| Header | Status | Bewertung | Wert / Hinweis |
|---|---|---|---|
| — | |||
Wann ist ein Security Header Check sinnvoll?
Ein Security Header Check ist besonders nützlich, wenn eine Website nach einem Relaunch, Server-Wechsel oder Änderungen an CDN, Proxy oder Hosting technisch sauber geprüft werden soll. Gerade in produktiven Umgebungen gehen Security Header häufig unbemerkt verloren oder werden uneinheitlich ausgeliefert.
Nach Relaunch oder Infrastruktur-Änderung
Bei Deployments, Server-Wechseln oder CDN-Anpassungen werden Header oft nicht vollständig übernommen oder durch neue Regeln verändert.
Bei Security Hardening
Wer Sicherheitsmaßnahmen technisch nachzieht, sollte prüfen, ob wichtige Header wie CSP, HSTS oder Referrer-Policy überhaupt vorhanden und sinnvoll gesetzt sind.
Bei CDN-, Proxy- oder WAF-Setups
In komplexeren Architekturen werden Header häufig an mehreren Stellen gesetzt. Dadurch entstehen schnell Inkonsistenzen oder unbeabsichtigte Überschreibungen.
Für technische QA
Ein schneller Header-Check hilft, technische Qualität sichtbar zu machen und fehlende Sicherheitsmechanismen frühzeitig zu erkennen.
Typische Fehler bei Security Headers
Probleme mit Security Headers entstehen häufig nicht, weil sie bewusst falsch gesetzt werden, sondern weil sie gar nicht vorhanden, zu allgemein konfiguriert oder an verschiedenen Stellen unterschiedlich ausgeliefert werden. Gerade bei Setups mit CDN, Reverse Proxy, Server, CMS oder App-Framework sind solche Inkonsistenzen typisch.
Wichtige Header fehlen komplett
Oft werden sicherheitsrelevante Header wie Content-Security-Policy, Strict-Transport-Security oder X-Content-Type-Options gar nicht gesetzt. Dann fehlen dem Browser wichtige Schutzmechanismen.
Content-Security-Policy ist zu schwach
Eine vorhandene CSP ist nicht automatisch gut. Wenn Regeln zu offen formuliert sind, etwa mit sehr großzügigen Freigaben, verliert die Policy schnell einen großen Teil ihrer Schutzwirkung.
HSTS fehlt trotz HTTPS
Wenn eine Website bereits sauber über HTTPS erreichbar ist, aber kein Strict-Transport-Security ausliefert, wird das Potenzial für eine konsequente HTTPS-Erzwingung nicht genutzt.
Widersprüche zwischen CDN, Proxy und Server
In komplexeren Setups setzen CDN, Reverse Proxy, Webserver oder Anwendung Header teilweise mehrfach oder unterschiedlich. Das führt zu uneinheitlichen, schwer nachvollziehbaren Security-Signalen.
Veraltete oder unpassende Header-Konfiguration
Manche Websites liefern noch ältere Header mit geringer Wirkung aus, während modernere und relevantere Policies fehlen oder nicht sauber gepflegt sind. Das wirkt technisch uneinheitlich und verschenkt Schutzpotenzial.
Zu strenge Regeln blockieren Funktionen
Security Headers können auch zu restriktiv konfiguriert sein. Dann werden Skripte, iFrames, externe Ressourcen oder eingebundene Dienste unbeabsichtigt blockiert. Deshalb sollten Sicherheitsregeln nicht nur vorhanden, sondern auch praxistauglich sein.
Worauf Sie besonders achten sollten
- wichtige Security Header sollten nicht fehlen
- Policies sollten bewusst und konsistent gesetzt sein
- Header-Konfigurationen aus CDN, Proxy und Server sollten zusammenpassen
- zu offene oder zu strenge Regeln sollten technisch geprüft und sauber abgestimmt werden
Wann reicht ein Security Header Check nicht mehr aus?
Ein Security Header Check ist ideal, um einen einzelnen Aspekt schnell zu prüfen. Wenn aber zusätzlich Title, Meta Description, Canonicals, Indexierung, interne Verlinkung, Statuscodes oder andere technische SEO-Signale Probleme machen, reicht ein Einzeltool oft nicht mehr aus.
Dann ist ein vollständiger Website-Check sinnvoll, um Onpage-, Technik- und Struktur-Signale im Zusammenhang zu prüfen und die wichtigsten Baustellen sauber zu priorisieren.
FAQ: Security Header Checker
Häufige Fragen rund um HTTP Security Header, Browser-Schutzmechanismen, typische Fehlkonfigurationen und die technische Einordnung von Sicherheits-Headern auf Websites.
Was ist ein Security Header Checker?
Ein Security Header Checker prüft, welche sicherheitsrelevanten HTTP-Header eine Website ausliefert. Dazu gehören zum Beispiel Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options oder Referrer-Policy. So lässt sich schnell erkennen, ob grundlegende Browser-Schutzmechanismen vorhanden sind oder wichtige Header fehlen.
Warum sind Security Header wichtig?
Security Header helfen Browsern dabei, Risiken besser zu begrenzen. Je nach Header können sie etwa den Umgang mit eingebetteten Skripten, Dateitypen, Referrer-Informationen oder HTTPS-Verbindungen steuern. Sie ersetzen keine sichere Anwendung, sind aber ein wichtiger zusätzlicher Schutz auf HTTP-Ebene.
Welche Header sind besonders wichtig?
Besonders häufig relevant sind Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, Referrer-Policy und Permissions-Policy. Welche Header konkret sinnvoll sind, hängt aber immer auch von Setup, Anwendung und Einbindung externer Ressourcen ab.
Was macht eine Content-Security-Policy?
Die Content-Security-Policy legt fest, aus welchen Quellen Skripte, Styles, Bilder, Frames oder andere Ressourcen geladen werden dürfen. Sie kann helfen, Risiken durch unerwünschte oder manipulierte Inhalte zu reduzieren. Eine CSP ist allerdings nur dann wirklich hilfreich, wenn sie sauber und passend konfiguriert ist.
Was bedeutet HSTS?
Strict-Transport-Security signalisiert dem Browser, dass eine Website nur per HTTPS aufgerufen werden soll. Das ist besonders sinnvoll, wenn HTTPS bereits sauber eingerichtet ist und dauerhaft erzwungen werden soll. Fehlt HSTS, obwohl die Website vollständig auf HTTPS läuft, bleibt oft unnötiges Schutzpotenzial ungenutzt.
Ist es schon gut, wenn die Header einfach vorhanden sind?
Nicht automatisch. Ein vorhandener Header ist nur der erste Schritt. Entscheidend ist, ob er auch sinnvoll konfiguriert ist. Eine zu offene Content-Security-Policy oder uneinheitliche Header-Ausgabe über CDN, Proxy und Server bringt oft deutlich weniger als eine bewusst abgestimmte Konfiguration.
Können Security Header auch Probleme verursachen?
Ja. Wenn Regeln zu streng oder unpassend gesetzt sind, können Skripte, externe Dienste, iFrames, Bilder oder andere Ressourcen unbeabsichtigt blockiert werden. Deshalb sollten Security Header nicht nur nach Checkliste aktiviert, sondern immer im realen Setup getestet und abgestimmt werden.
Warum unterscheiden sich Header manchmal je nach URL?
Security Header werden nicht immer global identisch ausgeliefert. Je nach Route, Dateityp, Anwendungslogik, CDN-Regel, Reverse Proxy oder Server-Konfiguration können Header auf verschiedenen URLs unterschiedlich gesetzt sein. Genau deshalb lohnt sich die Prüfung nicht nur auf der Startseite, sondern auch auf wichtigen Seitentypen.
Sind Security Header nur für große Websites relevant?
Nein. Auch kleinere Websites profitieren von sauber gesetzten Security Headern. Gerade Standard-Setups in CMS, Shops oder Frameworks liefern hier oft noch Lücken, veraltete Defaults oder inkonsistente Konfigurationen mit.
Wann ist ein Security Header Checker besonders sinnvoll?
Besonders sinnvoll ist das Tool nach Relaunches, Server-Wechseln, CDN- oder Proxy-Änderungen, Framework-Updates oder Security-Hardening-Maßnahmen. Auch bei technischen Audits, Kundenprojekten oder QA-Prozessen hilft ein schneller Check, fehlende oder widersprüchliche Header sichtbar zu machen.
Wann reicht ein Security Header Checker nicht mehr aus?
Ein Security Header Checker ist ideal für die schnelle technische Einordnung einzelner URLs. Wenn jedoch CSP-Regeln im Detail abgestimmt, Sicherheitsprobleme systematisch bewertet oder unterschiedliche Header-Konfigurationen über Anwendung, Proxy, CDN und Server hinweg bereinigt werden müssen, reicht ein Einzeltool oft nicht mehr aus. Dann ist eine tiefergehende technische Analyse sinnvoll.
Passende nächste Checks
Security Header sollten nicht isoliert betrachtet werden. Je nach Befund lohnt sich danach oft der Blick auf Response Header, HTTPS-Setup, Host-Konsistenz oder Statuscodes.