Security & CSP Checker liest die Antwortheader der Seite, auf der Sie sich befinden, und bewertet sie – Content Security Policy, HSTS, Referrer-Policy, die Cross-Origin-Familie und mehr – und schlüsselt dann die CSP-Anweisung nach Anweisung auf und benennt die Quellen, die sie schwächen.
Sicherheitsheader können leicht falsch sein und sind schwer zu überprüfen. Die Werte leben auf dem Server, die Richtlinien sind lange einzeilige Zeichenfolgen und die Fehler sind still: Eine Inhaltssicherheitsrichtlinie, die immer noch „unsicheres Inline“ zulässt, sieht aus wie eine Richtlinie, stoppt aber fast nichts. Die übliche Antwort besteht darin, Ihre URL in einen Online-Scanner einzufügen, was nur für Seiten funktioniert, die ein Scanner erreichen kann – keine Staging-Site, kein internes Tool, keine Seite hinter einem Login.
Dieses Tool überprüft die Seite vor Ihnen, wenn Sie so angemeldet sind, wie Sie sind. Es liest die Antwortheader des Dokuments und gibt jedem einen Pass, eine Warnung oder einen Fehler mit einer einfachen Erklärung: ob überhaupt ein CSP vorhanden ist, ob HSTS Browser auf HTTPS hält, ob MIME-Sniffing ausgeschaltet ist, ob Referrer vollständige URLs preisgeben und worauf die Cross-Origin-*-Header eingestellt sind. Es weist auch auf Header hin, die mehr verraten, als sie sollten, wie z. B. „Server“ und „X-Powered-By“, die Ihre genaue Framework-Version benennen.
Der CSP-Tab ist das Herzstück davon. Die Richtlinie ist in Anweisungen unterteilt, jede Quelle ist farblich gekennzeichnet und die Ergebnisse lesen sich wie eine Rezension: „unsafe-inline“ in script-src wird als Fehler markiert, „unsafe-eval“ und Wildcard-Ursprünge als Warnungen und data: in script-src als Bypass. Es kennt die Regeln, die Menschen zum Stolpern bringen – dass „unsafe-inline“ ignoriert wird, sobald eine Nonce oder ein Hash vorhanden ist, sodass dieser Fall eher eine Warnung als ein Fehler ist, und dass „strict-dynamic“ Host-Zulassungslisten ersetzt. Fehlende Direktiven werden ebenfalls angezeigt: kein Objekt-Quelle, keine Basis-URI, keine Frame-Vorfahren, keine Form-Aktion. Per Meta-Tag bereitgestellte Richtlinien und Nur-Bericht-Richtlinien werden separat angezeigt, da sie sich unterschiedlich verhalten.
Die Registerkarte „Verbindung“ deckt ab, was HTTPS tatsächlich tut: den TLS-Handshake, das maximale Alter von HSTS gegenüber dem einjährigen Schwellenwert, den das Vorladen erfordert, includeSubDomains und Preload-Flags sowie jede unsichere Unterressource oder jedes unsichere Formularziel, das eine HTTPS-Seite untergräbt. Eines wird nicht behauptet: Zertifikatsdetails. Keine Browsererweiterung kann die Zertifikatskette, den Aussteller oder das Ablaufdatum lesen. Anstatt diese zu erfinden, sagt das Tool, wo Sie suchen müssen – das Vorhängeschloss in Ihrer Adressleiste oder ein externer Dienst für die gesamte Kette.
CSP, HSTS,
Die Richtlinie wird in Anweisungen analysiert, wobei jede Quelle farblich gekennzeichnet ist, sodass ein gefährlicher Wert hervorgehoben wird, anstatt sich in einer 500-stelligen Header-Zeichenfolge zu verstecken.
Flags „unsafe-inline“, „unsafe-eval“, Wildcards und data: in script-src – behandelt „unsafe-inline“ jedoch als Warnung, wenn ein Nonce oder Hash dazu führt, dass Browser es ignorieren, und schreibt „strict-dynamic“ und report-uri gut.
Eine Richtlinie ohne object-src, base-uri, frame-ancestors oder form-action wird mit dem spezifischen Risiko gemeldet, das jede Lücke offen lässt, auch wenn default-src bereits eine davon abdeckt.
HSTS-Maximalalter im Vergleich zum einjährigen Preload-Schwellenwert, der TLS-Handshake-Zeit und jeder http://-Subressource oder jedem Formularziel, das eine HTTPS-Seite untergräbt, aufgelistet mit seinem Selektor.
Header werden von der Seite gelesen, die Sie bereits in Ihrer Sitzung anzeigen, sodass interne Tools und Vorproduktionsseiten überprüft werden können – keine öffentliche URL, die ein Scanner erreichen könnte.
Gehen Sie die Checkliste auf der echten Seite durch: Stellen Sie sicher, dass der CSP erzwungen wird und nicht nur für Berichte, HSTS auf ein Jahr eingestellt ist und immer noch nichts über http:// geladen wird.
Online-Header-Checker benötigen eine öffentliche URL. Dadurch wird die von Ihnen angezeigte Seite gelesen, sodass eine Staging-Umgebung hinter der Basisauthentifizierung oder einem VPN genauso einfach überprüft werden kann.
Sehen Sie auf einen Blick, ob eine lange Richtlinie tatsächlich etwas einschränkt oder ob „unsafe-inline“ und ein Wildcard-Host sie stillschweigend zur Dekoration gemacht haben.
Finden Sie das genaue Bild, Skript oder die Formularaktion immer noch über http:// auf einer HTTPS-Seite mit dem Selektor des Elements, anstatt durch die Konsole zu suchen.
Kopieren Sie einen datierten Bericht über jeden Header, seinen Wert und sein Urteil, um ihn einem Audit, einem Pentest-Follow-up oder einem Compliance-Fragebogen beizufügen.
Klicken Sie im DevSuite Pro-Dock auf das Symbol „Sicherheit und CSP“. Die Prüfung wird sofort ausgeführt und in der Zusammenfassung wird angezeigt, wie viele Header bestanden, gewarnt wurden oder fehlen.
Auf der Registerkarte „Header“ werden alle Sicherheitsheader mit ihrem Wert und einem Urteil aufgeführt. Darunter befinden sich die Informationsoffenlegungsprüfung und die CORS-Header des Dokuments.
Öffnen Sie die Registerkarte „CSP“ für die Ergebnisliste und dann die analysierten Anweisungen. Rote Quellen sind Misserfolge, bernsteinfarbene sind einen zweiten Blick wert, grüne sind das, was eine starke Politik nutzt.
Die Registerkarte „Verbindung“ umfasst HTTPS, den TLS-Handshake, HSTS und alle gemischten Inhalte. Klicken Sie für das Zertifikat selbst auf das Vorhängeschloss in der Adressleiste – keine Erweiterung kann es lesen.
Der Kopierbericht erstellt eine Klartextzusammenfassung jedes Urteils, der CSP-Ergebnisse und aller gemischten Inhalte, bereit für ein Ticket oder eine Sicherheitsüberprüfung.
Installieren Sie DevSuite Pro kostenlos und schalten Sie 71+ Entwickler-Tools für Ihren Browser frei.
