METHODE

Vibe-Coded Software

Eine überwiegend von KI-Tools generierte App, deren sicherheitskritische Pfade kein Mensch gelesen hat. Sie demot sauber und bricht vorhersehbar: fehlende Autorisierung, unvalidierter Input, geleakte Secrets. Der mit Abstand häufigste schwere Defekt ist ein funktionierender Login ohne serverseitige Prüfung, die User A daran hindert, die Daten von User B zu lesen.

Zuletzt geprüft: vonChristof Jori wiki ↗

Vibe-coded Software ist das Ergebnis von Vibe Coding: eine überwiegend von KI-Tools gebaute Anwendung, deren sicherheitsrelevante Teile kein Mensch gelesen hat. Sie definiert sich nicht dadurch, KI-generiert zu sein. Sie definiert sich durch das Fehlen eines menschlichen Reviews auf den Pfaden, wo ein Fehler echtes Geld, echte Daten oder einen echten Breach kostet. Viel KI-generierter Code ist reviewed, gehärtet und vollkommen sicher. Vibe-coded Software ist die Teilmenge, bei der das nicht passiert ist.

Das prägende Merkmal: Sie demot sauber und bricht vorhersehbar. Sauber, weil das Modell sehr gut darin ist, den Happy Path funktionieren zu lassen, den Pfad, den man im Demo abläuft. Vorhersehbar, weil die Fehler jedes Mal an derselben Handvoll Stellen clustern: Autorisierung, die prüft ob du eingeloggt bist, aber nicht ob du diesen Datensatz sehen darfst, Input dem vertraut statt der validiert wird, hartcodierte oder an den Browser ausgelieferte Secrets, kein Rate Limiting, kein Error Handling jenseits eines generischen Catch. Wer ein vibe-coded App auditiert hat, kann die Findings des nächsten erraten, bevor er es öffnet.

Beispiel, das kanonische. Eine Buchungs-App hat einen sauberen Login. Einmal drin holt die App deine Buchungen von /api/bookings/1234. Ändere 1234 auf 1235 und du siehst die Buchung von jemand anderem, dessen Name, dessen Adresse, dessen Zahlungsreferenz. Der Login fühlte sich sicher an, also prüfte niemand. Der Server hat nie verifiziert, dass der eingeloggte User die Buchung 1235 besitzt. Das nennt man einen Broken-Object-Level-Authorization-Bug, und er ist der mit Abstand häufigste schwere Defekt in vibe-coded Software, weil das Demo nie den Fall durchspielt, dass ein User nach den Daten eines anderen greift.

Der ehrliche Trade-off: Vibe-coded Software ist tatsächlich billiger und schneller zu produzieren, und für einen Prototyp ist das genau richtig. Der Preis ist, dass die Ersparnis vorgezogen ist und die Rechnung später kommt, als Breach, als DSGVO-Vorfall oder als Rewrite. Das zu benennen ist kein Anti-KI-Snobismus. Der Code kann vollkommen gut sein, sobald die fehlenden 10 % ergänzt sind. Der Fehler ist, die 90 % auszuliefern und anzunehmen, das Demo habe die übrigen 10 % bewiesen.

Wavect auditiert vibe-coded Software auf genau dieses Profil unter Software Quality Assurance. Wir lesen zuerst die Autorisierungspfade, weil dort der schlimmste und häufigste Bug lebt, dann Input-Validierung, Secrets und Error Handling, dann ergänzen wir die Regressions-Suite und das CI/CD-Gate, das die nächste Änderung daran hindert, das Loch wieder aufzureißen. Es ist kein Rewrite. Es ist, die von den Tools hinterlassene Technical Debt sichtbar zu machen und dann den Teil abzuzahlen, der dir schaden kann.

// FAQ

Häufige Fragen

Ein funktionierender Login ohne serverseitige Autorisierung. Die App prüft, dass du eingeloggt bist, aber nicht, dass du den konkreten angefragten Datensatz sehen darfst. Ändere eine ID in der URL und du liest die Daten eines anderen Users. Das Demo testet das nie, also fällt es niemandem auf, bis es ausgenutzt wird.
Lies die Autorisierungspfade. Wenn der Login die einzige Zugriffsprüfung ist und einzelne Datensätze nicht gegen den aktuellen User verifiziert werden, war es fast sicher vibe-coded. Weitere Anzeichen: Secrets im Client-Bundle, keine Input-Validierung, ein generischer Catch-all-Error-Handler und keine ernstzunehmende Test-Suite.
Nein. Es heißt, dass niemand die sicherheitskritischen Pfade gelesen hat. Der generierte Code ist auf dem Happy Path oft sauber und vernünftig. Das Problem sind die fehlenden 10 %, die Auth, Validierung und Secrets-Handling, nach denen der Prompt nie gefragt hat. Ergänze das und dieselbe Codebase kann produktionsreif sein.