HTTP-Security-Header-Test: HSTS, CSP & Co. prüfen

Dieser kostenlose Test bewertet die HTTP-Security-Header Ihrer Website in über 30 Einzelprüfungen – von HSTS über die Qualität der Content-Security-Policy bis zu Cookie-Flags, CORS, Mixed Content und Informationslecks – und liefert zu jedem Fund eine konkrete Empfehlung. Jetzt Domain prüfen →

Die fünf Pflicht-Header

Strict-Transport-Security (HSTS): erzwingt HTTPS und verhindert SSL-Stripping. Bewertet wird die Lebensdauer (max-age ≥ 1 Jahr für volle Punkte); max-age=0 ist ein Fehler, denn es löscht eine vorhandene Policy aktiv aus dem Browser. Zusätzlich prüft der Test die Voraussetzungen für die HSTS-Preload-Liste.
Content-Security-Policy (CSP): die wirksamste Schutzschicht gegen XSS – siehe unten.
X-Content-Type-Options: nosniff: verhindert, dass Browser Inhaltstypen erraten und z. B. Text als Skript ausführen.
Clickjacking-Schutz: heute über frame-ancestors in der CSP, X-Frame-Options dient als Fallback für alte Browser.
Referrer-Policy: begrenzt, welche URL-Daten beim Klick auf externe Links abfließen.

CSP richtig einsetzen

Eine reine Host-Allowlist mit unsafe-inline ist oft umgehbar – stark sind Nonce- oder Hash-basierte Policies mit strict-dynamic. Der Test bewertet deshalb nicht nur, ob eine CSP gesetzt ist, sondern wie gut: unsichere Quellen (unsafe-inline, unsafe-eval, Wildcards), Härtungs-Direktiven (object-src, base-uri, form-action), upgrade-insecure-requests, Trusted Types, Sandbox und ob Verstöße per Reporting gemeldet werden. Eine Policy, die nur im Report-Only-Modus läuft, schützt noch nicht.

Cookies: Secure, HttpOnly, SameSite

Cookies ohne Secure lassen sich über HTTP mitlesen, ohne HttpOnly per JavaScript stehlen (XSS), ohne SameSite für CSRF missbrauchen. Der Test prüft jedes gesetzte Cookie auf diese Attribute und erkennt zusätzlich die Namens-Präfixe __Host-/__Secure-, die die Attribute browserseitig erzwingen.

Veraltete Header entfernen

X-XSS-Protection: Der Browser-Auditor wurde entfernt und konnte selbst Lücken schaffen (XS-Leaks) – weglassen oder auf 0 setzen.
Expect-CT: obsolet, seit Certificate Transparency für alle Zertifikate verpflichtend ist.
HPKP (Public-Key-Pinning): zurückgezogen und von Browsern nicht mehr unterstützt – zu riskant im Betrieb.

Was der Test zusätzlich prüft

Cross-Origin-Isolation (COOP/COEP), Permissions-Policy, Origin-Agent-Cluster, Mixed Content, Subresource Integrity, CORS-Konfiguration (Access-Control-Allow-Origin-Wildcards), Cache-Control auf authentifizierten Antworten, Technologie-Preisgabe über Server-/X-Powered-By-Banner und die security.txt (RFC 9116). Die vollständige Bewertungslogik jedes Checks steht in den Erklärungen.

Häufige Fragen

Welche Security-Header sind die wichtigsten?

Fünf Header bilden die Basis: Strict-Transport-Security (HSTS) erzwingt HTTPS, die Content-Security-Policy begrenzt XSS-Schäden, X-Content-Type-Options: nosniff verhindert MIME-Sniffing, frame-ancestors (bzw. X-Frame-Options) schützt vor Clickjacking, und die Referrer-Policy begrenzt Datenabfluss über den Referer. Alles Weitere ist zusätzliche Härtung.

Sollte ich X-XSS-Protection noch setzen?

Nein. Der XSS-Auditor der Browser wurde entfernt und konnte selbst Sicherheitsprobleme verursachen (XS-Leaks). Der Header sollte weggelassen oder auf 0 gesetzt werden; den eigentlichen XSS-Schutz übernimmt heute die Content-Security-Policy.

Was unterscheidet den Test von securityheaders.com?

securityheaders.com hat das Header-Grading als eigenständiges Werkzeug etabliert. Dieser Test prüft die Header als eines von sechs Modulen im Kontext der ganzen Domain – zusätzlich unter anderem Cookie-Flags, CORS-Konfiguration, Cache-Control auf authentifizierten Antworten, Mixed Content und Informationslecks wie Server-Banner. Detaillierter Vergleich →

Quellen

RFC 6797 (HSTS) ↗ · W3C CSP Level 3 ↗ · OWASP Secure Headers Project ↗ · RFC 9116 (security.txt) ↗