1. Was ein Check liest
- Die Seite selbst: das ausgelieferte HTML und die Antwort-Header, wie bei einem normalen Besuch.
- Die Dateien, die Ihre Seite selbst lädt: JavaScript, nachgeladene Teile, Stylesheets und Konfigurationsdateien, nur von Ihrer eigenen Domain. Diese Dateien lädt auch jeder Browser.
- Das Zertifikat: Gültigkeit und Ablauf, über denselben TLS-Handschlag, den jeder Browser macht.
- Öffentliche DNS-Einträge: E-Mail-Schutz und Domain-Einstellungen, ohne mit Ihrem Server zu sprechen.
- Offene Schwachstellen-Datenbanken: Abgleich erkannter Software. Dorthin gehen nur Paketname und Version, nie Ihre Adresse.
Finden wir einen geheimen Schlüssel, benutzen wir ihn nie. Im Bericht stehen Art und Fundstelle, der Wert nur gekürzt, etwa sk_live_…9f2A.
2. Was wir nie tun
- Versteckte Pfade ausprobieren oder Dateien wie .env abrufen
- Dateien laden, die Ihre Seite nicht selbst einbindet oder abruft (außer der öffentlichen Datei /.well-known/security.txt), oder Skripte von fremden Domains lesen
- Offene Ports suchen (Port-Scan)
- Formulare absenden oder Angriffs-Code schicken
- Uns anmelden oder gefundene Schlüssel benutzen
- Vollständige Werte gefundener Schlüssel anzeigen oder speichern
- Interne oder private Adressen prüfen
Mehr dazu unter Was wir nicht prüfen und in den Nutzungsregeln.
3. So entsteht die Note
Schutz-Header bringen Punkte, Funde ziehen Punkte ab. Am schwersten wiegen ein offen liegender geheimer Schlüssel, eine Adresse, die Fremde übernehmen können, und eine Lücke, die laut der US-Behörde CISA aktiv ausgenutzt wird. Datenschutz- und DNS-Hinweise stehen im Bericht, ändern die Note aber nicht. Die Note misst die Angriffsfläche.
| Note | Punkte |
|---|---|
| A | 90 bis 100 |
| B | 75 bis 89 |
| C | 60 bis 74 |
| D | 40 bis 59 |
| E | 20 bis 39 |
| F | unter 20, oder kein HTTPS |
Jeder Fund bedeutet „möglicherweise betroffen“, kein Beweis. 100 Punkte heißen, dass keiner unserer Prüfpunkte anschlägt, nicht, dass die Seite sicher ist. Was hinter der Oberfläche liegt, etwa Datenbanken und Zugriffsrechte, sieht erst ein Security Audit.
4. Was wir prüfen
| Bereich | Was wir ansehen |
|---|---|
| Verschlüsselung und Zertifikat · 6 | Ob Ihre Seite verschlüsselt erreichbar ist und das Zertifikat gilt, also das Schloss im Browser. Fehlt eines davon, können Dritte mitlesen oder Besucher sehen eine Warnseite. |
| Schutz-Einstellungen für den Browser · 9 | Hausregeln, die Ihr Server dem Browser bei jedem Aufruf mitgibt, etwa: keine fremden Skripte ausführen. Fehlen sie, führt der Browser auch eingeschleusten Code aus. |
| Schutz gegen gefälschte Mails · 6 | Ob ein Eintrag bei Ihrem Domain-Anbieter festlegt, wer Mails in Ihrem Namen senden darf. Ohne ihn kommen gefälschte Rechnungen mit Ihrer Absenderadresse leichter durch. |
| Domain und DNS · 5 | Öffentliche Einträge Ihrer Domain: ob eine verwaiste Weiterleitung Fremden Ihre Adresse überlässt, wer Zertifikate ausstellen darf, ob DNSSEC aktiv ist und wohin Sicherheitsforscher Lücken melden. |
| Veraltete Software · 2 | Bausteine Ihrer Seite in Versionen, für die Sicherheitslücken öffentlich bekannt sind. |
| Quelltext und JavaScript-Dateien · 28 | Was jeder Besucher im Quelltext und in den JavaScript-Dateien Ihrer App lesen kann, zum Beispiel Schlüssel für Datenbank, KI-Dienste oder Zahlungen. |
| Datenschutz (DSGVO) · 5 | Typische Datenschutz-Fehler, die sich von außen belegen lassen und in Deutschland oft abgemahnt werden: Google Fonts von Google-Servern, Tracking vor der Einwilligung, eingebettete Inhalte und fehlende Pflichtlinks. Keine Rechtsberatung. |
| Cookies · 2 | Ob die Cookies Ihrer Seite vor Mitlesen und fremden Skripten geschützt sind. |
Jeder Befund ist den anerkannten Standards CWE, OWASP Top 10, OWASP ASVS und BSI IT-Grundschutz zugeordnet. Alle Prüfpunkte mit fester ID stehen unter Prüfpunkte.
5. Datenquellen
Bekannte Lücken gleichen wir live mit OSV.dev ab, aktiv ausgenutzte mit dem Katalog von CISA, die Wahrscheinlichkeit einer Ausnutzung mit FIRST EPSS und das Supportende mit endoflife.date. Software erkennen wir mit den offenen Regeln von webappanalyzer und Retire.js, Schlüssel mit eigenen Mustern und den Regeln von gitleaks. Jede Änderung prüfen wir vor dem Start an über 100 echten Seiten auf Fehlalarme.
Technische Einzelheiten wie Dateigrenzen, Punkte je Header und Abzüge stehen für Entwickler in der Doku unter Methode.