Beispielbericht

Ein Beispiel-Auditbericht

So sieht das Ergebnis eines Audits aus: jeder Befund mit Schweregrad, Beleg, Risiko in einfachen Worten und einer Empfehlung.

Beispiel: Dieser Bericht beschreibt eine erfundene Anwendung. Er enthält keinen echten Kunden, keine echten Daten und keine Zugangsdaten.

Zusammenfassung

Technik: Next.js, Supabase, ein Zahlungsanbieter, betrieben auf Vercel
Befunde: Kritisch: 1 Hoch: 3 Mittel: 3 Niedrig: 2
Empfehlung: Härten, nicht neu bauen. Anmeldung und Datenmodell sind tragfähig; die Befunde lassen sich in gezielten Arbeitspaketen beheben, beginnend mit den kritischen und hohen.

Befunde

F-01 Zeilenzugriff auf die Tabelle invoices ungeschützt

Kritisch Bereich: Security-Hardening

Beleg: Für die Tabelle invoices ist der zeilenweise Zugriffsschutz abgeschaltet, und der öffentliche Schlüssel, der mit der Browser-App ausgeliefert wird, kann jede Zeile lesen.
Risiko: Jeder Besucher kann die Rechnungen aller Kunden lesen, einschließlich Namen und Beträgen.
Empfehlung: Zeilen-Zugriffsregeln aktivieren, eine Regel ergänzen, die jede Zeile auf ihren Eigentümer beschränkt, und vor der Veröffentlichung mit zwei Konten testen.

Codesupabase/policies.sql

- -- noch keine Regel (Zeilenschutz ausgeschaltet)+ alter table invoices enable row level security;+ create policy "owner reads own invoices" on invoices+   for select using (auth.uid() = user_id);

F-02 Dienstschlüssel in der Git-Historie und im Browser-Bundle

Hoch Bereich: Security-Hardening

Beleg: Ein Schlüssel mit Administratorrechten steht in einem frühen Commit und ist in das JavaScript für den Browser einkompiliert.
Risiko: Wer die Entwicklerwerkzeuge des Browsers öffnet, kann als Administrator der Datenbank handeln.
Empfehlung: Den Schlüssel sofort erneuern, aus der Historie entfernen und Aufrufe, die ihn brauchen, in eine Server-Funktion verlagern, die ihn aus der Umgebung liest.

Codelib/supabase.ts

- const db = createClient(url, "sb_service_…")+ // nur serverseitig: dieses Modul nie im Client-Code importieren+ const db = createClient(url, process.env.SUPABASE_SERVICE_KEY!)

F-03 Admin-Routen sind nur im Browser geschützt

Hoch Bereich: Security-Hardening

Beleg: Das Admin-Menü ist für normale Nutzer ausgeblendet, aber die API-Routen unter /api/admin prüfen die Rolle des Nutzers nicht.
Risiko: Jeder angemeldete Nutzer kann Administrator-Funktionen direkt aufrufen.
Empfehlung: Die Rolle bei jeder Admin-Route auf dem Server prüfen und pro Route einen Test ergänzen, der für normale Nutzer eine Ablehnung erwartet.

F-04 Der Zahlungs-Webhook akzeptiert gefälschte und wiederholte Anfragen

Hoch Bereich: Stabilisierung & Refactoring

Beleg: Der Webhook prüft die Signatur des Zahlungsanbieters nicht und legt bei jeder Zustellung eine neue Rechnung an, auch bei Wiederholungen.
Risiko: Eine gefälschte Anfrage kann eine Rechnung als bezahlt markieren, und eine Wiederholung bucht dieselbe Zahlung doppelt.
Empfehlung: Signatur prüfen, jede Ereignis-Kennung speichern und bereits verarbeitete Ereignisse ignorieren.

Codeapi/webhook.ts

  export async function POST(req: Request) {-   const event = await req.json()+   const event = verifySignature(req, process.env.WEBHOOK_SECRET!)+   if (await alreadyProcessed(event.id)) return new Response(null, { status: 200 })

F-05 Anmeldung und Passwort-Zurücksetzen ohne Begrenzung

Mittel Bereich: Security-Hardening

Beleg: Die Endpunkte für Anmeldung und Passwort-Zurücksetzen akzeptieren beliebig viele Versuche pro Adresse und pro Konto.
Risiko: Passwörter lassen sich durch automatisierte Versuche erraten, und die Rücksetz-Mail lässt sich nutzen, um einen Nutzer zu überfluten.
Empfehlung: Versuche pro Konto und pro Adresse begrenzen, eine kurze Sperre ergänzen und Nutzer bei wiederholten Fehlversuchen benachrichtigen.

F-06 Keine Tests, durchgehend any-Typen und kopierter Datenzugriff

Mittel Bereich: Stabilisierung & Refactoring

Beleg: Es gibt keine automatisierten Tests, die meisten Funktionen sind mit any typisiert, und dieselbe Abfrage ist in viele Komponenten kopiert.
Risiko: Jede Änderung kann Unbeteiligtes zerstören, und niemand merkt es, bis ein Nutzer es meldet.
Empfehlung: Zuerst Tests rund um Abrechnung und Anmeldung ergänzen, any in der Datenschicht ersetzen und die kopierten Abfragen in ein Modul verlagern.

F-07 Staging nutzt die Produktionsdatenbank, Backups wurden nie wiederhergestellt

Mittel Bereich: Production-Readiness & Betrieb

Beleg: Die Staging-Seite ist mit der Datenbank-URL der Produktion konfiguriert, und die Backup-Einstellung ist aktiv, doch eine Wiederherstellung wurde nie versucht.
Risiko: Ein Test kann Kundendaten zerstören, und ein nie wiederhergestelltes Backup funktioniert im Ernstfall vielleicht nicht.
Empfehlung: Staging eine eigene Datenbank geben, das letzte Backup einmal dorthin zurückspielen und die Schritte aufschreiben.

F-08 Zwei Abhängigkeiten mit bekannten Sicherheitslücken hoher Schwere

Niedrig Bereich: Audit & Triage

Beleg: Die Abhängigkeitsprüfung nennt zwei Pakete mit bekannten Sicherheitslücken hoher Schwere, beide indirekt eingebunden.
Risiko: Bekannte Schwachstellen lassen sich ausnutzen, ohne die App selbst zu kennen.
Empfehlung: Pakete aktualisieren oder ersetzen, automatische Update-Prüfungen aktivieren und die Prüfung vor jeder Veröffentlichung wiederholen.

F-09 Keine Fehlerüberwachung und kein Health-Check

Niedrig Bereich: Production-Readiness & Betrieb

Beleg: Fehler sind nur in der Browser-Konsole sichtbar, und es gibt keinen Endpunkt, der einem Monitor sagt, ob die App läuft.
Risiko: Ausfälle und fehlschlagende Zahlungen bemerken zuerst die Kunden.
Empfehlung: Fehler-Tracking, einen Health-Endpunkt und einen Alarm an eine Person ergänzen und in der Staging-Umgebung prüfen.

Das Gleiche für Ihre App?

Wir beginnen mit einem Audit mit festem Umfang. Sie erhalten einen Bericht wie diesen für Ihren eigenen Code.

Audit anfragen Oder prüfen Sie zuerst Ihre Readiness