Lesen Sie die HTTP-Security Headers aus, die eine Website tatsächlich sendet, und finden Sie heraus, welche davon fehlen, Schwachstellen aufweisen oder sich stillschweigend gegenseitig aufheben. Kostenlos, ohne Registrierung.
HTTP-Security Headers sind Anweisungen, die ein Webserver mit jeder Antwort sendet, um bereits im Browser vorhandene Schutzmechanismen zu aktivieren: welche Quellen Skripte ausführen dürfen, ob die Website über unverschlüsseltes HTTP geladen werden darf und ob eine andere Website sie in einem Frame einbinden darf. Der „ReportedIP Security Header Check“ liest diese Header aus, bewertet jeden einzelnen danach, was er tatsächlich verhindert, und nennt für jede Lücke die konkrete Änderung.
Die meisten Header-Prüfprogramme liefern Ihnen eine Checkliste und eine Bewertung. Dabei wird ein fehlender „Permissions-Policy“-Header als ebenso großes Problem behandelt wie ein fehlender „Content-Security-Policy“-Header, was jedoch nicht der Fall ist. Der eine schränkt die Möglichkeiten einer Browser-API ein; der andere entscheidet darüber, ob ein Cross-Site-Script ausgeführt wird oder nicht.
Diese Prüfung bewertet jeden Header danach, was er verhindert. Die „Content-Security-Policy“ zählt am meisten, gefolgt von HSTS, dem Framing-Schutz und dem Content-Type-Sniffing. Header zur domänenübergreifenden Isolierung werden zwar gemeldet, aber mit null Punkten bewertet, da eine Website, die diese nie benötigt hat, dafür keine Punkte verlieren sollte.
Eine Website mit einer ordnungsgemäßen Content-Security-Policy benötigt den älteren Header nicht, und die Forderung nach beidem ist ein Ratschlag aus der Zeit vor zehn Jahren. Eine rein meldende Richtlinie zählt nicht, da Browser diese nicht durchsetzen.
Es weist den Browser aktiv an, zu vergessen, dass die Website jemals ausschließlich über HTTPS erreichbar war. Eine Checkliste sieht einen vorhandenen Header und hakt das Kästchen ab.
Browser ignorieren es dort, daher lässt die Prüfung es bei der Berechnung außer Acht, anstatt dafür Punkte abzuziehen.
Die Seite wird mit einer normalen GET-Anfrage abgerufen, nicht mit HEAD, da manche Server die beiden Anfragen unterschiedlich beantworten und nur die Header, die ein Browser sieht, von Bedeutung sind. Es werden ausschließlich die Antwort-Header überprüft; der Seiteninhalt wird nicht gespeichert.
Die Adresse wird mit einer normalen GET-Anfrage abgerufen, wobei bis zu drei Weiterleitungen durchlaufen werden, und die Antwort-Header werden ausgelesen. Es wird GET anstelle von HEAD verwendet, da eine beträchtliche Anzahl von Servern, Reverse-Proxys und Firewalls auf HEAD-Anfragen über einen anderen Codepfad mit einem reduzierten Header-Satz antworten, wodurch Header als fehlend gemeldet würden, die ein echter Browser tatsächlich erhält. Die Überprüfung wird von diesem Server aus durchgeführt; daher kann es vorkommen, dass eine Website, die ihre Header je nach Land, User-Agent oder Login-Status variiert, Ihnen eine andere Antwort liefert.
Die Bewertung erfolgt gewichtet und nicht als bloße Zählung. „Content-Security-Policy“ und „Strict-Transport-Security“ haben das größte Gewicht, da sie darüber entscheiden, ob eingefügte Skripte ausgeführt werden und ob eine Anfrage auf reines HTTP zurückgeführt werden kann. „Referrer-Policy“ und „Permissions-Policy“ begrenzen Datenlecks und haben ein geringeres Gewicht. COOP, COEP und CORP haben keinerlei Gewichtung: Sie dienen dazu, Seiten zu isolieren, die hochauflösende Timer benötigen, und eine Website, die diese nicht benötigt, ist nicht weniger sicher, wenn sie darauf verzichtet.
„X-Frame-Options“ wird nicht als fehlend gemeldet, wenn in der „Content-Security-Policy“ „frame-ancestors“ festgelegt ist. „frame-ancestors“ ist die festgelegte Nachfolgeoption, wird von allen aktuellen Browsern unterstützt und ermöglicht die Nennung einzelner zulässiger Ursprünge, was mit „X-Frame-Options“ nie möglich war. Eine Content-Security-Policy, die ausschließlich in der Form „Report-Only“ gesendet wird, wird als das behandelt, was sie ist: ein Messinstrument, das Verstöße aufzeichnet und nichts blockiert.
Es wird nur eine Seite gelesen. Header werden in der Regel auf Server- oder Proxy-Ebene festgelegt und gelten daher überall; eine Anwendung kann sie jedoch pro Route hinzufügen oder entfernen. Daher ist es sinnvoller, die relevante Seite, also die Seite des Logins oder die Kasse, zu überprüfen, als die Startseite. Das Tool liest ausschließlich Header und überprüft niemals den Seiteninhalt; daher kann es nicht feststellen, ob eine Richtlinie tatsächlich umfassend genug ist, damit die Website ordnungsgemäß funktioniert.