Sicherheitsheader-Prüfer

Gib die URL einer Website ein, um zu prüfen, ob wichtige Sicherheitsheader wie HSTS, CSP und X-Frame-Options korrekt konfiguriert sind. Sieh, welche Header fehlen oder schwach sind, samt Tipps zur Behebung.

Tipps

  • Dieses Tool ruft die Ziel-URL serverseitig ab und kann daher die Header jeder Website prüfen, ohne an CORS-Beschränkungen des Browsers zu scheitern.
  • Ein längerer HSTS-max-age-Wert ist grundsätzlich sicherer, aber wenn du eine Änderung der Zertifikatsverwaltung planst, teste zunächst mit einem kürzeren Wert, bevor du ihn produktiv einsetzt.
  • Kombiniere dieses Tool mit dem Schwestertool CSP-Validator (dev.server.csp_validator), um die tatsächliche Syntax deiner Content-Security-Policy im Detail zu prüfen.
  • Dieses Tool nutzt denselben Mechanismus "URL eingeben und serverseitig abrufen" wie der robots.txt-Prüfer und kann daher jede öffentlich zugängliche Seite ohne Authentifizierung prüfen.
  • Prüfe deine eigene Website regelmäßig, um sicherzustellen, dass eine Konfigurationsänderung an einem CDN oder Reverse-Proxy nicht stillschweigend einen Sicherheitsheader entfernt hat.

Häufig gestellte Fragen

Der Funktionsumfang ist ähnlich, aber der Prüfer von Toolbase ermöglicht es, Ergebnisse und Korrekturerklärungen auf Japanisch einzusehen. Die detaillierte CSP-Syntaxprüfung übernimmt das Schwestertool CSP-Validator.

Ja, aber da HSTS nur bei HTTPS-Verbindungen sinnvoll ist, wird der HSTS-Punkt bei einer reinen HTTP-Website immer als nicht bestanden diagnostiziert. Priorisiere zunächst die vollständige Umstellung der Website auf HTTPS.

Aktuell wird die frame-ancestors-Direktive der Content-Security-Policy empfohlen, aber da einige ältere Browser sie nicht unterstützen, ist es in der Praxis üblich, beide als doppelte Schutzebene anzugeben.

Nein. Die Anfrage an die eingegebene URL erfolgt nur im Moment der Prüfung, und die abgerufenen Header-Informationen werden niemals auf dem Server gespeichert.

Nicht unbedingt. Insbesondere Permissions-Policy ist eine optionale zusätzliche Schutzebene, deren Priorität je nach Art der Website geringer sein kann. Wir empfehlen, zunächst wirkungsvolle Punkte wie HSTS, CSP und X-Frame-Options zu verbessern.
ツールくん

Übrigens – securityheaders.com und die Geschichte der Clickjacking-Abwehr

Die Diagnose von Sicherheitseinstellungen anhand von HTTP-Antwortheadern wird seit Langem von securityheaders.com dominiert, entwickelt von Scott Helme. Da viele ausländische Dienste Ergebnisse und Korrekturvorschläge nur auf Englisch erklären, hat Toolbase einen eigenen Prüfer entwickelt, mit dem Ergebnisse und Erklärungen gemeinsam auf Japanisch eingesehen werden können – als Alternative in diesem Bereich.

HSTS (HTTP Strict Transport Security) wurde 2012 vom IETF als RFC 6797 standardisiert. Der Ursprung geht auf eine 2009 vorgeführte Demonstration von "SSL Stripping" zurück, einem Angriff, der den kurzen Moment ausnutzt, in dem ein Nutzer eine URL ohne https:// eingibt und der Browser sich zunächst unverschlüsselt per HTTP verbindet, wodurch ein Angreifer den Datenverkehr umschreiben kann. HSTS lässt einen Browser sich merken, dass "diese Domain immer über HTTPS aufgerufen werden muss", und verhindert so Downgrade-Angriffe nach dem ersten Besuch.

X-Frame-Options war ursprünglich ein proprietärer Erweiterungsheader, den Microsoft 2009 für den Internet Explorer 8 einführte und der später von anderen Browsern übernommen wurde und sich zu einem De-facto-Standard entwickelte. Das damalige Problem war "Clickjacking", bei dem ein unsichtbares iframe über einen echt aussehenden Button gelegt wird, sodass Nutzer unbemerkt klicken. Heute bewegt sich die Branche in Richtung der flexibleren frame-ancestors-Direktive der Content-Security-Policy, aber die Angabe beider Header wird weiterhin als Absicherung für ältere Browser empfohlen, die diese nicht unterstützen.

→ Verwandte Wissenstexte lesen

→ Alle Wissenstexte ansehen

Weitere Tools in dieser Kategorie