System Audit

Das kostenlose Audit prüft, was von außen sichtbar ist. Das System-Audit geht mit einem Lesezugang hinter die Anmeldung – für Shopsysteme, CMS, CRM und eigene Webanwendungen. Es ist kostenpflichtig und beginnt immer mit einer Anfrage, nie mit einem Zugang.

Vorgehensweise

1. 1

   Anfrage

   Du schilderst kurz, um welches System es geht und worum es dir dabei geht. Zugangsdaten gehören nicht in dieses Formular.

2. 2

   Vorgespräch und Angebot

   Wir klären den Umfang und was geprüft werden soll. Du bekommst ein schriftliches Angebot mit Aufwand und Preis. Erst danach geht es weiter.

3. 3

   Zugang einrichten

   Du legst ein eigenes Konto mit Leserechten an – kein geteiltes Admin-Passwort. Je nach System auch API-Token, Basic-Auth oder Session-Cookie. Der Zugang gilt nur für den vereinbarten Zeitraum.

4. 4

   Prüfung

   Öffentlicher Teil automatisiert, Backend je nach System automatisiert oder manuell. Es wird nur gelesen: nichts geändert, nichts installiert, nichts gelöscht.

5. 5

   Bericht und Besprechung

   Du bekommst den Bericht mit Freigabeurteil, Einzelbefunden, Phasenplan und Kostenindikation – auf Wunsch mit Durchsprache.

6. 6

   Zugang entziehen

   Nach Abschluss löschst du das Konto beziehungsweise widerrufst den Token. Das ist Teil des Ablaufs, keine Bitte am Rande.

Ladezeit: gemessen, nicht geschätzt

Beim System-Audit gilt dasselbe wie bei der kostenlosen Prüfung: Die Ladezeit kommt aus Google PageSpeed Insights und nicht aus einer eigenen Faustregel. Der Bericht führt dazu getrennt auf:

• Den Laborwert. Google Lighthouse misst unter genormten Bedingungen – gedrosseltes Mobilfunknetz, Mittelklassegerät, leerer Cache. Reproduzierbar, und damit die Grundlage, um vorher und nachher zu vergleichen. Enthalten sind LCP, FCP, Speed Index, Total Blocking Time und CLS mit Einzelbewertung.
• Die Felddaten. Was echte Besucher in den letzten 28 Tagen erlebt haben, aus dem Chrome UX Report. Das ist der Wert, nach dem Google rankt. Jede Metrik erscheint als Tortendiagramm: wie viele Besucher gut, verbesserungswürdig oder schlecht bedient wurden. Eine einzelne Zahl verschweigt genau das – ein mittelmäßiger Schnitt kann heißen, dass alle mittelmäßig laden, oder dass die meisten sehr schnell laden und eine Minderheit sehr langsam. Nur der zweite Fall hat eine klare Ursache.
• Die Einzelmaßnahmen. Lighthouse beziffert je Maßnahme den Zeitgewinn in Sekunden und das eingesparte Volumen. Der Bericht sortiert danach, sodass die Reihenfolge der Arbeit feststeht.

Hat eine Domain zu wenig Verkehr, veröffentlicht Google keine Felddaten. Der Bericht sagt das dann ausdrücklich, statt eine Lücke zu lassen – es ist keine schlechte Note, sondern eine Auskunft über die Datenlage.

Anfrage stellen

Code-Analyse

Von außen ist der Quelltext unsichtbar – die häufigsten schweren Fehler stecken aber genau dort. Liegt der Code vor (Repository-Zugang oder Archiv), wird er zusätzlich gegen einen festen Regelkatalog geprüft:

• Geheimnisse im Code – Schlüssel, Token, Passwörter, versehentlich eingecheckte .env-Dateien
• SQL ohne Platzhalter, unescapte Ausgaben, fehlende Eingabebereinigung – die Wege zu SQL-Injection und XSS
• Fehlende Rechte- und Nonce-Prüfungen vor schreibenden Aktionen
• Tracking vor der Einwilligung im Template
• Entwicklungsartefakte im Auslieferungsstand: Debug-Ausgaben, Testzugänge, offene Konfiguration

Das Ergebnis ist eine Liste mit Datei und Zeile, dazu die Regel, die verletzt wurde – nachvollziehbar und wiederholbar prüfbar.

Was du bekommst

• Bericht über den öffentlichen und den angemeldeten Teil
• Befunde aus der Code-Analyse mit Datei und Zeile, sofern Code vorliegt
• Benutzerkonten, Rollen und verwaiste Zugänge
• Plugin- und Theme-Stände samt bekannter Schwachstellen
• Ausstehende Updates mit Dringlichkeit
• Konfigurationsfehler und Systemdiagnose
• Phasenplan mit Aufwand und Kostenindikation