Sicherheitsaudit für Vibe-Coded Apps: Was wir finden und beheben

Deine Vibe-Coded-Anwendung funktioniert. Nutzer registrieren sich, Daten fließen, das Produkt gewinnt an Fahrt. Aber es gibt eine Frage, die niemand im Team sicher beantworten kann: Ist sie sicher?

In den meisten Fällen lautet die ehrliche Antwort: Nein – oder zumindest: nicht ausreichend. KI-generierter Code übernimmt die Sicherheitsmuster (und Anti-Muster) aus seinen Trainingsdaten. Ohne Expert-Review deployen Vibe-Coded-Anwendungen konsequent mit Schwachstellen, die von peinlich bis katastrophal reichen.

Das ist kein theoretisches Problem. In den Jahren 2025–2026 haben mehrere Startups mit Vibe-Coded-Produkten Datenpannen, Account-Übernahmen und Compliance-Failures erlebt, die sich direkt auf ihr Geschäft auswirkten. Das Muster ist so konsistent geworden, dass das Sicherheitsauditieren von Vibe-Coded-Anwendungen zu einer eigenständigen Disziplin geworden ist.

Dieser Beitrag erläutert, was wir bei Audits von Vibe-Coded-Apps finden, warum diese Schwachstellen entstehen und wie der Behebungsprozess aussieht.

Warum KI-generierter Code Sicherheits-Blindstellen hat

KI-Code-Generierungsmodelle werden auf riesigen Mengen öffentlichen Codes trainiert. Dieser Code enthält sowohl sichere als auch unsichere Muster. Das Modell unterscheidet nicht zwischen ihnen – es generiert, was zum Prompt passt. Mehrere Faktoren machen das problematischer:

Häufige Muster sind nicht immer sichere Muster. Die am häufigsten vorkommende Authentifizierungsimplementierung in öffentlichen Repositories ist nicht die sicherste. Sie ist die schnellste zu schreiben. KI-Modelle optimieren für „sieht aus wie typischer Code" – nicht für „erfüllt OWASP-Top-10-Standards".

Sicherheit dreht sich um das, was fehlt – nicht nur was vorhanden ist. Ein Vibe-Coded-Login-Endpoint könnte Passwörter hashen und ein Token zurückgeben – die positive Funktionalität funktioniert. Aber er könnte Rate Limiting, Account-Lockout nach fehlgeschlagenen Versuchen, Constant-Time-Vergleich und sicheres Token-Storage vermissen lassen. Sicherheit lebt in den Lücken.

Kontextabhängige Sicherheit ist für KI schwer. Ob ein bestimmter Ansatz sicher ist, hängt vom Deployment-Kontext ab – ist das ein internes Tool oder ein öffentliches SaaS? Sind die Daten reguliert? Wer sind die wahrscheinlichen Angreifer? KI-Modelle stellen diese Fragen nicht. Sie generieren Code, der funktioniert, unabhängig vom Bedrohungsmodell.

Feature-für-Feature-Prompting übersieht übergreifende Concerns. Wenn du „füge einen Nutzerprofil-Endpoint hinzu" und dann „füge ein Admin-Dashboard hinzu" promptest, generiert die KI jedes unabhängig. Sie berücksichtigt nicht, ob das Admin-Dashboard ordnungsgemäß einschränkt, welche Profile ein Admin sehen kann, oder ob der Profil-Endpoint Daten preisgibt, die das Admin-Dashboard als privat betrachtet.

Die 10 häufigsten Schwachstellen in Vibe-Coded-Anwendungen

Nach der Prüfung Dutzender Vibe-Coded-Anwendungen aus SaaS, E-Commerce, FinTech und internen Tools sind dies die Schwachstellen, die am häufigsten auftreten:

1. Fehlerhafte Authentifizierung

Was wir finden:

• JWT-Tokens ohne Ablaufzeit – ein gestohlener Token funktioniert für immer
• Refresh-Tokens, die nie rotiert werden – ihre Kompromittierung gibt permanenten Zugriff
• Passwortvergleich mit === statt konstantem Zeitvergleich (Timing-Angriff)
• Kein Rate Limiting auf dem Login-Endpoint – Brute-Force-Angriffe gelingen in Minuten
• Passwort-Reset-Tokens, die nicht ablaufen oder wiederverwendet werden können
• Session-Tokens in localStorage gespeichert, zugänglich für jede XSS-Payload

Schweregrad: Kritisch. Authentifizierung ist die Eingangstür. Wenn sie kaputt ist, ist alles dahinter exponiert.

Behebung: Token-Generierung durch eine sichere Bibliothek ersetzen, Token-Ablauf und -Rotation implementieren, Rate Limiting und Account-Lockout hinzufügen, Session-Tokens zu httpOnly-Cookies mit secure- und SameSite-Flags verschieben.

2. Fehlerhafte Zugriffskontrolle (IDOR)

Was wir finden:

• API-Endpoints, bei denen das Ändern des ID-Parameters die Daten eines anderen Nutzers zurückgibt: /api/users/123/invoices gibt Rechnungen für Nutzer 123 zurück, unabhängig davon, wer anfrägt
• Multi-Tenant-Anwendungen, bei denen die Tenant-Isolation im Frontend-Routing, aber nicht in den Datenbankabfragen existiert
• Admin-Funktionen, die für normale Nutzer zugänglich sind, weil die Autorisierung nur in der UI geprüft wird
• File-Upload/-Download-Endpoints, die beliebige Dateien nach ID ohne Eigentumsverifikation ausliefern

Schweregrad: Kritisch. Dies ist die #1-Schwachstelle in den OWASP Top 10, und sie ist in KI-generiertem Code allgegenwärtig, weil die KI keine Autorisierungsabsicht modelliert – sie baut nur den Datenzugriffspfad.

Behebung: Serverseitige Autorisierungsprüfungen auf jeden Endpoint hinzufügen. Ein Middleware- oder Decorator-Muster implementieren, das verifiziert, dass der anfragende Nutzer Zugriff auf die angeforderte Ressource hat. Client-seitiger Autorisierung niemals vertrauen.

3. SQL-Injection und NoSQL-Injection

Was wir finden:

• Rohe SQL-Abfragen mit String-Konkatenation oder Template-Literalen: `SELECT * FROM users WHERE email = '${email}'`
• MongoDB-Abfragen aus unsanitiertem Nutzer-Input: { username: req.body.username } (NoSQL-Injection über $gt, $ne-Operatoren)
• ORM-Nutzung, die die Parametrisierung umgeht: Rohe Abfragen eingebettet in ansonsten sicheren ORM-Code
• GraphQL-Resolver, die Nutzer-Input direkt an Datenbankabfragen weitergeben

Schweregrad: Kritisch. Injection kann zu vollem Datenbankzugriff, Datenexfiltration, Datenveränderung und in manchen Fällen zu Remote Code Execution führen.

Behebung: Alle rohen SQL-Abfragen durch parametrisierte Abfragen oder ORM-Methoden ersetzen. Alle Nutzer-Inputs vor Erreichen jeglicher Abfrageebene validieren und sanitieren. Automatisiertes SAST-Scanning hinzufügen, das rohe Abfragemuster flaggt.

4. Cross-Site Scripting (XSS)

Was wir finden:

• Nutzer-generierter Content ohne Sanitierung gerendert – Namen, Bios, Kommentare, Nachrichten
• dangerouslySetInnerHTML in React-Komponenten, die Nutzer-Input verarbeiten
• Serverseitiges Template-Rendering, das Output nicht escaped
• Fehlende Content-Security-Policy-Header
• Markdown-Rendering ohne Sanitierung (erlaubt eingebettetes HTML/JavaScript)

Schweregrad: Hoch. XSS kann Session-Tokens stehlen, Nutzer umleiten, die Anwendung verunstalten und als Ausgangspunkt für sophistiziertere Angriffe dienen.

Behebung: Sicherstellen, dass alle nutzer-generierten Inhalte vor dem Rendering escaped werden. Unnötige dangerouslySetInnerHTML-Nutzung entfernen. Content-Security-Policy-Header implementieren. Eine Sanitierungsbibliothek für Inhalte verwenden, die HTML oder Markdown unterstützen müssen.

5. Sensitive Datenoffenbarung

Was wir finden:

• API-Responses, die Felder enthalten, die nicht in der UI angezeigt werden – interne IDs, E-Mail-Adressen anderer Nutzer, Erstellungszeitstempel, Soft-Delete-Flags, Datenbank-Metadaten
• Fehler-Responses, die Stack Traces, SQL-Abfragen, Dateipfade und Umgebungsvariablennamen enthalten
• Debug-Logging, das sensible Daten (Passwörter, Tokens, PII) in Anwendungslogs schreibt
• API-Keys, Datenbank-Credentials und Third-Party-Geheimnisse im Quellcode hartcodiert oder in der Git-History

Schweregrad: Hoch. Datenoffenbarung ermöglicht weitere Angriffe und verstößt gegen Datenschutzbestimmungen. Credentials in der Git-History bleiben auch nach Code-Änderungen bestehen.

Behebung: Explizite API-Response-Serialisierung implementieren – genau definieren, welche Felder jeder Endpoint zurückgibt, statt vollständige Datenbankobjekte zurückzugeben. Fehlerbehandlung konfigurieren, um Nutzern generische Meldungen zu zeigen, während Details serverseitig geloggt werden. Git-History auf Geheimnisse prüfen und alle exponierten rotieren. Umgebungsbasiertes Secrets-Management implementieren.

6. Fehlendes Rate Limiting

Was wir finden:

• Kein Rate Limiting auf irgendeinem Endpoint – die gesamte API akzeptiert unbegrenzte Anfragen
• Login-Endpoints anfällig für Credential Stuffing und Brute-Force-Angriffe
• Passwort-Reset-Endpoints, die für E-Mail-Bombing genutzt werden können
• API-Endpoints, die teure Operationen auslösen (Berichterstellung, E-Mail-Versand) ohne Drosselung
• Webhook-Endpoints, die unbegrenzte Payloads akzeptieren

Schweregrad: Mittel-Hoch. Fehlendes Rate Limiting ermöglicht Denial-of-Service, Brute-Force-Angriffe, Ressourcenerschöpfung und Funktionsmissbrauch.

Behebung: Rate Limiting auf API-Gateway- oder Anwendungsebene implementieren. Strengere Limits für Authentifizierungs-Endpoints anwenden. Nutzer- und IP-basiertes Throttling hinzufügen. Rate-Limit-Header konfigurieren, damit Clients Backoff implementieren können.

7. Unsicheres Datei-Handling

Was wir finden:

• Datei-Uploads ohne Typvalidierung – Nutzer können ausführbare Dateien hochladen
• Keine Dateigrößen-Limits – ein Upload kann die Festplatte füllen
• Hochgeladene Dateien von derselben Domain ohne Content-Type-Einschränkungen ausgeliefert (gespeichertes XSS über SVG- oder HTML-Dateien)
• Aus Nutzer-Input konstruierte Dateipfade ohne Sanitierung (Path Traversal)
• Kein Malware-Scanning für hochgeladene Dateien

Schweregrad: Mittel-Hoch. Unsicheres Datei-Handling kann zu Remote Code Execution, gespeichertem XSS, Denial of Service und Datenexfiltration führen.

Behebung: Dateitypen nach Inhalt validieren (nicht nur Extension), Größen-Limits erzwingen, Uploads von einer separaten Domain oder CDN mit restriktiven Headers ausliefern, Dateipfade sanitieren und Virenscanning für Anwendungen implementieren, die Datei-Uploads von nicht vertrauenswürdigen Nutzern akzeptieren.

8. Fehlende Security-Header

Was wir finden:

• Kein Content-Security-Policy-Header (CSP)
• Kein X-Content-Type-Options-Header (MIME-Sniffing-Angriffe)
• Kein Strict-Transport-Security-Header (HSTS-Bypass)
• Kein X-Frame-Options oder frame-ancestors CSP-Direktive (Clickjacking)
• Permissive CORS-Konfiguration (Access-Control-Allow-Origin: * mit Credentials)

Schweregrad: Mittel. Jeder fehlende Header ist eine Defense-in-Depth-Lücke, die andere Schwachstellen leichter ausnutzbar macht.

Behebung: Security-Header auf Webserver- oder Anwendungsebene konfigurieren. Mit einer restriktiven CSP beginnen und bei Bedarf lockern. HSTS mit angemessenem max-age aktivieren. CORS auf spezifische vertrauenswürdige Origins beschränken.

9. Unzureichendes Logging und Monitoring

Was wir finden:

• Kein Logging von Authentifizierungsereignissen (erfolgreiche oder fehlgeschlagene Logins)
• Kein Logging von Autorisierungsfehlern (Access-Denied-Ereignisse)
• Kein Logging von Datenveränderungsereignissen (Erstellen, Aktualisieren, Löschen)
• Kein Alerting bei verdächtigen Mustern (mehrfache fehlgeschlagene Logins, ungewöhnlicher Datenzugriff)
• Logs, die PII ohne angemessene Zugriffskontrollen enthalten

Schweregrad: Mittel. Ohne Logging kannst du Angriffe nicht erkennen, Incidents nicht untersuchen oder Compliance-Anforderungen nicht erfüllen. Ohne Monitoring bleiben Breaches monatelang unentdeckt.

Behebung: Strukturiertes Logging für alle sicherheitsrelevanten Ereignisse implementieren. Alerting für verdächtige Muster einrichten. Sicherstellen, dass Logs keine sensiblen Daten (Passwörter, Tokens) enthalten, aber Korrelations-IDs für Tracing haben. Log-Retention gemäß Compliance-Anforderungen konfigurieren.

10. Abhängigkeits-Schwachstellen

Was wir finden:

• Veraltete npm/composer-Pakete mit bekannten CVEs
• Kein automatisiertes Dependency-Scanning
• Nicht committete Lock-Files (nicht-reproduzierbare Builds)
• Dev-Abhängigkeiten in Production-Builds enthalten
• Pakete aus ungepflegten oder schlecht reputierten Quellen

Schweregrad: Variabel (hängt von der spezifischen Schwachstelle ab, kann aber kritisch sein). Abhängigkeits-Schwachstellen sind der einfachste Angriffsvektor, weil sie gut dokumentiert sind und oft öffentliche Exploits haben.

Behebung: npm audit oder äquivalent ausführen, anfällige Pakete aktualisieren, automatisiertes Dependency-Scanning in CI/CD hinzufügen, ungenutzte Abhängigkeiten entfernen und den Wartungsstatus kritischer Abhängigkeiten bewerten.

Wie ein Sicherheitsaudit-Engagement aussieht

Phase 1: Automatisiertes Scanning (Tag 1)

• Static Application Security Testing (SAST)-Scan der gesamten Codebasis
• Abhängigkeits-Schwachstellen-Scan (npm audit, Snyk oder äquivalent)
• Secret-Detection-Scan (Prüfung auf hartcodierte Credentials, API-Keys, Tokens)
• Infrastructure-Konfigurationsprüfung (falls zutreffend)
• Output: Rohe Findings zur Triage in Phase 2

Phase 2: Manuelle Prüfung (Tage 2–4)

• Authentifizierungs- und Autorisierungs-Flow-Review
• Datenzugriffsmuster-Analyse (wer kann was zugreifen und wird das durchgesetzt?)
• Input-Validierungsbewertung über alle Endpoints
• API-Response-Review (Prüfung auf Datenlecks)
• Business-Logic-Sicherheits-Review (können Nutzer Preise manipulieren, Limits umgehen, Privilegien erhöhen?)
• Output: Validierte Findings mit Schweregradeinstufungen und Exploit-Szenarien

Phase 3: Bericht und Behebungsplan (Tag 5)

• Priorisierter Schwachstellenbericht mit:
  • Beschreibung jedes Findings
  • Schweregrad (Kritisch / Hoch / Mittel / Niedrig)
  • Exploit-Szenario (wie ein Angreifer es nutzen würde)
  • Spezifische Behebungsanleitung (nicht „Schwachstelle beheben", sondern „diesen Code so ändern")
  • Geschätzter Behebungsaufwand
• Empfohlene Behebungsreihenfolge basierend auf Risiko vs. Aufwand
• Architekturempfehlungen zur Verhinderung von Wiederholungen

Phase 4: Behebungsunterstützung (Woche 2–3)

• Kritische und hochgradige Schwachstellen beheben
• Security-Header und CSP implementieren
• Automatisiertes Security-Scanning in CI/CD einrichten
• Security-fokussiertes Logging und Monitoring hinzufügen
• Fixes mit Re-Testing verifizieren
• Output: Saubere Scan-Ergebnisse, dokumentierte Sicherheitslage

Nach dem Audit: Sicherheit aufrechterhalten

Ein Sicherheitsaudit ist eine Momentaufnahme. Um Sicherheit bei der Weiterentwicklung der Anwendung aufrechtzuerhalten:

• Automatisiertes Scanning in CI/CD: Jeder Pull Request erhält einen SAST-Scan und eine Abhängigkeitsprüfung
• Sicherheitsfokussiertes Code-Review: Neue Features, die Auth, Datenzugriff oder Nutzer-Input berühren, erhalten explizites Sicherheits-Review
• Periodische Neubewertung: Vierteljährlich oder nach wichtigen Feature-Launches die Sicherheitslage neu bewerten
• Abhängigkeits-Updates: Monatliche Prüfung und Aktualisierung von Drittanbieter-Paketen
• Incident-Response-Plan: Dokumentieren, was zu tun ist, wenn (nicht ob) eine Sicherheitslücke entdeckt wird

Wichtigste Erkenntnisse

• KI-generierter Code deployt konsequent mit Sicherheitslücken, weil KI-Modelle für Funktionalität optimieren – nicht für Sicherheit
• Die 10 häufigsten Probleme sind gut verstanden und behebbar – aber sie erfordern eine Fachbewertung, um sie zu finden
• Ein strukturiertes Sicherheitsaudit dauert 1–2 Wochen: automatisiertes Scanning, manuelle Prüfung, priorisierter Bericht und Behebung
• Sicherheitslücken blockieren Enterprise-Sales, erzeugen rechtliche Risiken unter der DSGVO und verursachen irreversiblen Vertrauensschaden, wenn sie ausgenutzt werden
• Nach dem Audit halten automatisiertes Scanning und periodische Neubewertungen die Anwendung sicher, während sie sich weiterentwickelt

Deine Vibe-Coded-Anwendung sichern, bevor es zu spät ist

Wolf-Tech bietet Sicherheitsaudits, die speziell für KI-generierte und Vibe-Coded-Anwendungen entwickelt wurden. Wir finden die Schwachstellen, priorisieren nach realem Risiko und beheben sie – damit dein Team sich mit Zuversicht auf das Wachstum des Produkts konzentrieren kann. Hol dir eine kostenlose Beratung, um die Sicherheitslage deiner Anwendung zu besprechen.