10001
Was bedeutet der Score?
Jede Kategorie startet bei 100. Nur nicht bestandene Findings ziehen deterministisch Punkte nach Severity und Confidence ab.
- Kein KI-erfundener Wert
- Abzüge im Appendix sichtbar
- Overall ist der gewichtete Lagewert
?Interpretation / Support
Klar lesen.
Richtig handeln.
SiteGuard ist ein technisches Frühwarn- und Priorisierungswerkzeug. Diese Seite erklärt, wie Scores und Findings zu lesen sind, was typische Fehler bedeuten und wann eine manuelle Prüfung notwendig bleibt.
SG/??Kontext schlägt EinzelwertScore, Severity, Confidence und Evidenz gemeinsam bewerten
01Die entscheidenden
Fachinhalt
Die entscheidenden
Bausteine.
04 MODULE
KLAR BESCHRIEBEN
!02
Severity und Confidence
Severity beschreibt die mögliche Auswirkung. Confidence beschreibt, wie belastbar die technische Beobachtung aus öffentlichen Signalen ist.
- High Confidence: direkt beobachtet
- Medium: plausible technische Einordnung
- Low: manuell verifizieren
40403
Report nicht verfügbar
Das ist nach einer erfolgreichen Einmal-Auslieferung erwartetes Verhalten und kein Datenverlust auf dem Server – dort sollte nichts verbleiben.
- Browser-Reload vermeiden
- PDF oder JSON sofort exportieren
- Bei Bedarf neuen Audit starten
ERR04
Scan fehlgeschlagen
Nicht erreichbare Domains, blockierte Zieladressen, zu große Antworten, Rate-Limits oder Zeitbudgets können einen Lauf kontrolliert beenden.
- Öffentliche Erreichbarkeit prüfen
- URL ohne Login-Daten verwenden
- Nach kurzer Pause erneut versuchen
02
Ablauf
Findings sinnvoll bearbeiten
01
Evidenz lesen
Betroffene Header, URLs oder DOM-Elemente nachvollziehen.
02
Kontext prüfen
Confidence und dokumentierte Grenzen berücksichtigen.
03
Ursache beheben
Zentrale Komponente oder Serverkonfiguration korrigieren.
04
Erneut messen
Neuen Audit ausführen und Ergebnis vergleichen.
03 / BOUNDARY
Was der Report nicht beweist.
Ein unauffälliger Public Audit beweist weder vollständige Sicherheit noch Rechtskonformität. Umgekehrt ist eine Konfigurationsschwäche nicht automatisch eine ausgenutzte Schwachstelle.
Kein PenetrationstestKeine RechtsberatungKeine authentifizierten BereicheKein aktiver Rate-Limit-TestKeine vollständigen Core Web VitalsKeine manuelle Screenreader-Prüfung
04Antworten ohne
Frequently Asked
Antworten ohne
Kleingedrucktes.
01Warum werden nur bis zu 25 Seiten geprüft?+
Das feste Limit hält den Audit reproduzierbar, risikoarm und zeitlich begrenzt. Die Auswahl entsteht aus echten Links und der Sitemap; aggressive Enumeration findet nicht statt.
02Warum kann ich einen Report nicht neu laden?+
Der fertige Report wird beim ersten terminalen Abruf aus dem Server-RAM entfernt. Danach liegt er nur noch in der bereits geöffneten Browseransicht vor.
03Ist ein Low-Finding unwichtig?+
Nicht zwingend. Low bedeutet geringe automatisiert eingeschätzte Auswirkung. Wiederkehrende Low-Findings können auf eine systematische Template- oder Prozessschwäche hinweisen.
04Warum fehlen LCP, CLS und INP?+
Diese Werte benötigen einen vollständigen Browserlauf beziehungsweise reale Nutzerdaten. Der sichere axe-Browser lädt bewusst keine fremden Ressourcen, damit Seiten keine internen Ziele ansprechen können.
05Kann SiteGuard Login-Sicherheit prüfen?+
Passiv ja: öffentlich sichtbare Passwortformulare, Transport, Ziel, Feldattribute sowie sichtbare CSRF-, Rate-Limit-, CAPTCHA-, MFA- und Passkey-Signale werden bewertet. SiteGuard verarbeitet keine Credentials, sendet kein Formular ab und betritt keine authentifizierten Bereiche. Die tatsächliche Wirksamkeit von Rate-Limiting lässt sich so weder bestätigen noch widerlegen.
Nächster Schritt