Zum Inhalt springen
ipaddress.fi

Security-Header-Prüfung

Wir laden die Antwort-Header einer öffentlichen URL (ohne Inhalt) und prüfen die Schutz-Header einzeln.

Beispiele:

Einige der wirksamsten Schutzmaßnahmen im Web sind einfache HTTP-Antwort-Header, einmal auf dem Server gesetzt. Die Prüfung lädt die Antwort-Header einer öffentlichen URL, folgt Weiterleitungen bis zur endgültigen Seite und prüft sie einzeln:

  • Strict-Transport-Security lässt Browser nur HTTPS verwenden.
  • Content-Security-Policy begrenzt, woher Skripte und andere Ressourcen geladen werden dürfen, und mit frame-ancestors, wer die Seite einbetten darf.
  • X-Content-Type-Options: nosniff verhindert, dass Browser Dateitypen raten.
  • Referrer-Policy bestimmt, wie viel von der URL an andere Sites weitergegeben wird.
  • Permissions-Policy schaltet Browserfunktionen ab, die die Site nicht nutzt.
  • Cross-Origin-Opener-Policy isoliert die Seite von Fenstern, die sie öffnet.

Außerdem werden in Server oder X-Powered-By offengelegte Softwareversionen markiert. Das Ergebnis ist eine Checkliste, keine Sicherheitsnote: Header sind eine Schutzschicht unter vielen.

Häufig gestellte Fragen

Warum gilt HSTS unter sechs Monaten als schwach?

Browser merken sich die HTTPS-Pflicht nur max-age Sekunden lang. Sechs Monate bis ein Jahr sind die übliche Empfehlung und Voraussetzung für die Preload-Listen der Browser.

Wird X-Frame-Options noch gebraucht?

Die CSP-Direktive frame-ancestors ersetzt es in modernen Browsern. Hier zählt jede der beiden als Frame-Schutz.

Sendet das Tool etwas anderes als eine normale Anfrage?

Nein. Es sendet pro Weiterleitungsschritt eine gewöhnliche GET-Anfrage, liest nur die Header und schließt die Verbindung.

Verwandt