Zum Inhalt springen
Pro-Funktion

Enthalten im Pro- und im Agency-Plan.

HTTP-Security-Header auf einen Blick

Prüft zehn Security-Header einer URL – von CSP und HSTS bis Permissions-Policy – mit Score, Erklärung und konkretem Implementierungshinweis.

10 Prüfungen Ergebnis in Sekunden Security-Header öffnen Pläne ansehen

Sicherheitsheader sind der erste Verteidigungsring einer Website – und gleichzeitig der am häufigsten vernachlässigte. Sie werden im Browser nicht sichtbar, wirken aber stillschweigend: Ohne Content-Security-Policy ist jede XSS-Lücke sofort ausnutzbar, ohne HSTS reicht ein einmaliger HTTP-Aufruf, um die Verbindung zu kompromittieren.

Der Security-Header-Check ruft die Zieladresse ab, liest die HTTP-Response-Header aus und bewertet zehn Sicherheitsheader einzeln. Für jeden Header gibt es den aktuellen Wert, eine Erklärung der Wirkung und – falls der Header fehlt oder schwach konfiguriert ist – einen konkreten Implementierungshinweis.

Was geprüft wird

Content-Security-Policy

Der wichtigste moderne Security-Header: kontrolliert, welche Ressourcen geladen werden dürfen. Wirksamer XSS-Schutz – Voraussetzung ist eine restriktive default-src-Regel ohne unsafe-inline.

Strict-Transport-Security

Zwingt Browser, die Seite nur über HTTPS aufzurufen. Schützt vor Protocol-Downgrade-Angriffen. Ideal: max-age=31536000; includeSubDomains; preload.

X-Frame-Options

Verhindert Clickjacking durch Frame-Einbettung. DENY oder SAMEORIGIN – oder alternativ CSP frame-ancestors.

X-Content-Type-Options

Verbietet dem Browser, den Content-Type zu erraten. Verhindert MIME-Sniffing-Angriffe mit einem einzigen Wert: nosniff.

Referrer-Policy

Bestimmt, wie viel URL-Information an Dritte übergeben wird. Empfohlen: strict-origin-when-cross-origin oder restriktiver.

Permissions-Policy

Kontrolliert Zugriff auf Browser-APIs wie Kamera, Mikrofon oder Geolocation. Reduziert die Angriffsfläche gezielt.

Cross-Origin-Header

COOP, CORP und COEP isolieren den Browsing-Kontext gegen Spectre-ähnliche Angriffe und steuern die Einbettung von Cross-Origin-Ressourcen.

Bewertung mit Score

Jeder Header hat ein Gewicht (CSP 20, HSTS 15, …) und wird als vorhanden, unvollständig, schwach oder fehlend eingestuft – daraus ergibt sich ein Score von 0 bis 100.

Implementierungshinweise

Bei jedem fehlenden oder schwachen Header erscheint ein konkreter Konfigurationsvorschlag mit dem vollständigen Header-String zum Kopieren.

Verlauf

Die letzten 15 Prüfungen bleiben gespeichert – so lässt sich der Effekt einer Server-Umstellung vorher/nachher belegen.

So läuft die Prüfung

  1. 1

    Adresse eingeben

    Die URL genügt – fehlt das Protokoll, wird https:// ergänzt.

  2. 2

    Header auslesen

    Die Seite wird abgerufen und die Response-Header werden einzeln auf Sicherheitsrelevanz geprüft.

  3. 3

    Lücken schliessen

    Jeder Befund enthält den konkreten Header-String, der in der Server-Konfiguration ergänzt werden muss.

Warum das für die Sichtbarkeit zählt

Security-Header wirken prophylaktisch: Sie verhindern Angriffe, bevor sie stattfinden. Eine fehlende Content-Security-Policy bedeutet, dass ein einziger eingeschleuster Script-Tag beliebige Daten exfiltrieren kann. Ein fehlender HSTS-Header erlaubt es einem Angreifer im gleichen Netzwerk, die Verbindung auf HTTP downzugraden und Session-Cookies zu stehlen.

Die meisten Header lassen sich mit einer Zeile in der Server-Konfiguration setzen – der Aufwand ist minimal, der Schutz massiv. Der Check zeigt genau, welche Zeile fehlt und wie sie lauten muss.

Häufige Fragen

Welche Header werden geprüft?

Zehn Stück: Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, Cross-Origin-Opener-Policy, Cross-Origin-Resource-Policy, Cross-Origin-Embedder-Policy und X-XSS-Protection (veraltet, wird als Info gemeldet).

Warum ist der Score so niedrig, obwohl meine Seite über HTTPS läuft?

HTTPS allein reicht nicht – HSTS, CSP und die anderen Header müssen aktiv gesetzt sein. Eine typische Seite ohne explizit konfigurierte Security-Header erreicht maximal 15 bis 20 Punkte.

Ist X-Frame-Options noch relevant?

Ja, für Abwärtskompatibilität mit älteren Browsern. Moderne Browser werten CSP frame-ancestors vor – wenn das vorhanden ist, ist X-Frame-Options überflüssig und der Check meldet das korrekt.

Was bedeutet „schwach" bei CSP?

Eine CSP, die unsafe-inline oder unsafe-eval enthält, schwächt den XSS-Schutz erheblich. Der Check empfiehlt dann, auf Nonce-basierte CSP umzusteigen.

Weitere Werkzeuge