Website-Exposure-Scan — finde die offenen Türen, bevor es ein Angreifer tut.

Nein. Es ist strikt nicht-intrusive Erkundung: read-only GET-Anfragen an öffentliche URLs auf der Site, deren Besitz du nachgewiesen hast. Es sendet nie Exploit-Payloads, macht kein Brute-Force bei Logins, fuzzt keine Eingaben und ändert nichts – es kann also keinen laufenden Shop beschädigen. Außerdem weist es sich in der Anfrage als Relvato aus, statt wie ein heimlicher Angreifer zu agieren.

Der Schwachstellen-Scan prüft deine installierten Plugins und Themes gegen bekannte CVEs – es geht um verwundbaren Code. Der Exposure-Scan prüft Konfiguration und was von außen erreichbar ist – offene Dateien, offene Endpunkte, schwache Header –, was kein Code-Scanner sieht. Sie ergänzen sich: der eine findet verwundbare Software, der andere offene Türen.

Ja. Die generischen Tests – in Seiten und Skripten veröffentlichte Schlüssel, Source Maps, Cookie- und CORS-Regeln, offene Dateien, Directory Listing, fehlende Sicherheits-Header – gelten für jede Website; die WordPress-spezifischen Proben (XML-RPC, REST-Benutzer-Enumeration, Readme-Version) greifen anderswo schlicht nicht. Ein Plugin ist nicht nötig. Auf WordPress ergänzt es den Teil, den nur der Server sieht: was tatsächlich im Web-Root liegt und welche Einstellungen jeden anderen Fehler vergrößern.

Es ist bewusst schonend: eine kleine, kuratierte Liste von Anfragen mit niedriger Rate, jede mit kurzem Timeout, von einem ausgewiesenen User-Agent. Es läuft nur auf einer von dir verifizierten Domain, und du entscheidest dich per Aktivierung des Monitors dafür. Es ist derselbe nicht-intrusive erste Durchgang, den ein Sicherheitsprofi auf einer Site fährt, die er testen darf.

Ein offengelegtes Secret oder Backup lässt den Monitor anschlagen und alarmiert dich sofort – das sind Sofort-schließen-Probleme. Hardening-Lücken (fehlende Header, aktiviertes XML-RPC, Enumeration) werden als Warnungen zur Durchsicht gemeldet. Was auf deiner Site erwartet ist, kannst du als geprüft markieren, damit es nicht erneut nervt.

Sollte nicht passieren. Der größte Teil des Scans ist gewöhnlicher Verkehr – die Seiten und Skripte, die ein Browser ohnehin lädt. Der Teil, der Dateien wie /.env anfragt, ist genau das, wofür eine Server-Firewall gebaut ist. Deshalb stellt Relvato solche Anfragen nur, wenn sie sich lohnen: Mit installiertem Plugin fragt es deine Website, welche dieser Dateien wirklich existieren, und fordert nur diese an. Weist deine Firewall sie doch ab, meldet der Lauf, dass die Dateiprüfung abgelehnt wurde, statt ein sauberes Ergebnis.

Nein. Fragt Relvato deine Website von innen, besteht die Antwort aus Namen und Größen – niemals aus Inhalten. Dieser Endpunkt antwortet nur für Pfade innerhalb deines Web-Roots und weist alles ab, was daraus ausbrechen will; ein Befund zeigt höchstens die ersten Zeichen eines Schlüssels, damit der Bericht nicht selbst zum Leck wird.

Auf WordPress mit dem Relvato-Plugin haben acht häufige Funde einen Ein-Klick-Fix, den du in WordPress → Relvato anwendest und dort jeweils wieder abschalten kannst — vom Abschalten von XML-RPC bis zum Ergänzen sicherer Security-Header. Einen Content-Security-Policy- oder HSTS-Header fügt Relvato nie automatisch hinzu: Ein falscher Wert kann bei beiden eine Website lahmlegen, deshalb muss sie ein Mensch setzen.

Ja, ab WordPress 6.9 mit dem Relvato-Plugin ab 1.43.0. Plugins können Abilities registrieren, die KI-Assistenten und die REST API aufrufen können. Der Scan listet sie von innen auf und fragt den eigenen Permission-Callback jeder Ability, als abgemeldeter Besucher, ob jeder sie ausführen darf, ohne sie auszuführen. Eine Ability, die jeder ausführen kann und die nicht nur liest, wird als ernst gemeldet; offene lesende, löschende, die KI-Assistenten nutzen können, und nach einem Update neue sind Warnungen.