KI-App-Builder haben Millionen Menschen ohne Programmierausbildung zu Softwareherstellern gemacht. Allein Lovable meldet rund 8 Millionen Nutzer und mehr als 200.000 neue Projekte pro Tag (TechCrunch). Viele dieser Apps verarbeiten inzwischen echte Kundendaten, nehmen echte Zahlungen an und steuern echte Prozesse – auch in deutschen Mittelständlern, wo die Vertriebsleiterin sich „mal eben“ ein Angebots-Tool gebaut hat.
Die unbequeme Wahrheit: Eine App, die in der Demo perfekt läuft, kann trotzdem jedem angemeldeten Nutzer erlauben, die Daten aller anderen zu lesen – indem er eine einzige Zahl in einer Anfrage ändert. Generatoren optimieren auf das, was man auf dem Bildschirm sieht. Sicherheit ist unsichtbar, bis sie versagt.
Dieser Leitfaden liefert eine praxistaugliche Audit-Checkliste für Apps aus Lovable, Bolt, Replit, Cursor und ähnlichen Werkzeugen. Er erklärt, wo solche Apps typischerweise brechen, wie ein kurzes Rettungs-Audit abläuft und wie Sie zwischen Reparatur, Refactoring und Neubau entscheiden.
Das Ausmaß des Problems in Zahlen
Die Befunde aus 2025 und 2026 sind eindeutig:
- 5.600 öffentliche Apps gescannt, über 2.000 schwere Schwachstellen. Das Sicherheitsunternehmen Escape fand außerdem 400 offengelegte Secrets und 175 Fälle geleakter personenbezogener Daten (SoftwareSeni).
- CVE-2025-48757: Bei 170 von 1.645 geprüften Lovable-Apps lagen Daten offen, weil Row Level Security deaktiviert war (Cloud Security Alliance, The Next Web).
- Auch die Plattformen selbst sind nicht immun. Im April 2026 machte eine BOLA-Lücke in Lovable fremden Code und Datenbank-Zugangsdaten 48 Tage lang zugänglich (The Next Web).
- 406 Millionen Datensätze legte die App Chat & Ask AI offen – wegen einer Firebase-Regel, die schlicht alles erlaubte (CSA).
- Rund 55 % des KI-generierten Codes sind sicher – so Veracodes Tests, und dieser Wert ist trotz besserer Modelle nicht gestiegen (SoftwareSeni).
- 19,7 % der von Modellen vorgeschlagenen Pakete existieren nicht – ein Geschenk für Angreifer, die genau diese Namen registrieren („Slopsquatting“) (CSA).
Das heißt nicht, dass die Werkzeuge nutzlos sind. Es heißt: Eine generierte App ist ein erster Entwurf, der noch nie einen Sicherheitsprüfer gesehen hat.
Wo Vibe-Coding-Apps brechen: fünf wiederkehrende Schwachstellen
1. Zugriffsregeln der Datenbank
Viele Builder kombinieren ein Frontend mit Supabase oder Firebase. Der Browser spricht mit einem öffentlichen Schlüssel direkt mit der Datenbank. Das ist so gewollt – solange Zugriffsregeln festlegen, wer welche Zeile lesen und schreiben darf. In Supabase heißt das Postgres Row Level Security (RLS), in Firebase sind es Security Rules. Ist RLS für eine Tabelle aus oder steht in einer Regel sinngemäß „lesen und schreiben: immer erlaubt“, ist die Tabelle für jeden öffentlich, der die Browser-Konsole öffnet.
Typische Befunde: RLS auf den ersten Tabellen aktiv, auf später ergänzten nicht; Richtlinien, die nur „ist angemeldet“ prüfen statt „gehört dieser Datensatz dem Nutzer“; Storage-Buckets mit hochgeladenen Dokumenten auf öffentlich gestellt; der Service-Role-Key, der alle Regeln umgeht, im Browser ausgeliefert.
2. Autorisierung in der API
Authentifizierung beantwortet „Wer sind Sie?“. Autorisierung beantwortet „Dürfen Sie diesen Datensatz anfassen?“. Generierter Code erledigt oft das Erste und vergisst das Zweite. Das Ergebnis heißt Broken Object Level Authorization (BOLA): Ändern Sie /rechnungen/1042 in /rechnungen/1043, sehen Sie die Rechnung eines anderen Kunden. Nicht ohne Grund steht BOLA ganz oben in den OWASP API Security Top 10.
Ein zweites Muster ist Sicherheit durch Verstecken: Der Admin-Button ist für normale Nutzer unsichtbar, aber der Admin-Endpunkt dahinter prüft die Rolle nicht.
3. Secrets am falschen Ort
API-Schlüssel der Modellanbieter, geheime Zahlungsschlüssel und Datenbank-Zugangsdaten landen im Frontend-Bundle, in eingecheckten Umgebungsdateien oder im Systemprompt einer KI-Funktion. Den Schlüssel aus dem letzten Commit zu löschen, reicht nicht: In der Git-Historie bleibt er, bis er rotiert wird.
4. Abhängigkeiten, die niemand ausgewählt hat
Generierte Projekte ziehen Dutzende Pakete nach. Manche sind veraltet und haben bekannte Schwachstellen, manche hat – siehe 19,7 % – das Modell erfunden, und inzwischen hat sie womöglich jemand anderes registriert. Ohne Lockfile und Abhängigkeitsprüfung weiß niemand, was in Produktion wirklich läuft.
5. Ungeschützte KI-Endpunkte
Ruft Ihre App ein Sprachmodell auf, kommen zwei neue Risiken hinzu. Prompt Injection: Nutzertexte oder hochgeladene Dokumente enthalten Anweisungen, die Ihre eigenen aushebeln. Kostenmissbrauch: Ein Endpunkt ohne Rate Limits und Budgetgrenzen erlaubt jedem, Ihre Modellrechnung in die Höhe zu treiben. Abwehrmaßnahmen beschreiben wir ausführlich in Prompt Injection und Agentensicherheit.
Der 30-Minuten-Selbsttest, bevor Sie jemanden beauftragen
Die gefährlichsten Probleme können Sie an Ihrer eigenen App selbst erkennen:
- Öffnen Sie das Datenbank-Dashboard (Supabase, Firebase o. Ä.) und listen Sie alle Tabellen und Storage-Buckets auf. Notieren Sie, wo Zugriffsregeln aktiv sind. Jede Tabelle ohne Regeln ist ein Alarmsignal.
- Durchsuchen Sie das ausgelieferte Frontend nach Secrets. Öffnen Sie die Website, sehen Sie sich in den Entwicklertools des Browsers die JavaScript-Dateien an und suchen Sie nach Zeichenfolgen wie
sk_,secret,service_roleoder dem Schlüsselpräfix Ihres Modellanbieters. Ein öffentlicher „anon“- oder „publishable“-Key ist normal, ein geheimer Schlüssel nicht. - Legen Sie zwei Testkonten an. Erstellen Sie mit dem ersten einen Datensatz und kopieren Sie dessen ID aus der Adresszeile oder dem Netzwerk-Tab. Melden Sie sich mit dem zweiten an und rufen Sie diese ID auf. Lädt sie, haben Sie ein BOLA-Problem.
- Rufen Sie Admin-Seiten als normaler Nutzer auf, indem Sie die URL direkt eintippen. Lädt irgendetwas, ist der Schutz nur kosmetisch.
- Prüfen Sie, wer hochgeladene Dateien sieht. Öffnen Sie den Link zu einem Dokument in einem privaten Browserfenster. Öffnet es sich ohne Login, ist der Bucket öffentlich.
- Werfen Sie einen Blick auf die Nutzungsseite Ihres Modellanbieters. Unerklärliche Spitzen können bedeuten, dass jemand Ihren KI-Endpunkt gefunden hat.
Schlägt einer dieser Tests fehl: keine neuen Funktionen, erst die Grundlagen reparieren. Bestehen alle, brauchen Sie trotzdem die vollständige Checkliste – diese sechs Tests decken die lautesten Probleme ab, nicht alle.
Die Audit-Checkliste: 24 Punkte
Nutzen Sie die Tabelle als Arbeitsliste. Die Schwere beschreibt die typische Auswirkung, wenn der Punkt nicht erfüllt ist.
| # | Bereich | Was prüfen | Schwere |
|---|---|---|---|
| 1 | Datenbank | RLS (oder gleichwertige Regeln) auf jeder Tabelle aktiv, auch auf später ergänzten | Kritisch |
| 2 | Datenbank | Richtlinien prüfen Eigentum oder Rolle, nicht nur „angemeldet“ | Kritisch |
| 3 | Datenbank | Getrennte Richtlinien für Lesen, Anlegen, Ändern und Löschen | Hoch |
| 4 | Storage | Buckets mit Nutzerdateien privat; Links signiert und befristet | Kritisch |
| 5 | Schlüssel | Service-Role- oder Admin-Schlüssel ausschließlich auf dem Server | Kritisch |
| 6 | Autorisierung | Jede API-Route und Serverfunktion prüft den Zugriff auf genau diesen Datensatz | Kritisch |
| 7 | Autorisierung | Admin-Funktionen serverseitig geschützt, nicht nur in der Oberfläche versteckt | Kritisch |
| 8 | Authentifizierung | Passwort-Reset, E-Mail-Änderung und Einladungen nicht kaperbar | Hoch |
| 9 | Authentifizierung | Sitzungen laufen ab; Tokens nicht unnötig für Skripte lesbar gespeichert | Mittel |
| 10 | Secrets | Frontend-Bundle ohne geheime Schlüssel (gebautes JavaScript durchsuchen) | Kritisch |
| 11 | Secrets | Git-Historie gescannt; jeder offengelegte Schlüssel rotiert, nicht nur gelöscht | Kritisch |
| 12 | Secrets | Systemprompts ohne Schlüssel, interne URLs oder vertrauliche Regeln | Hoch |
| 13 | Abhängigkeiten | Jedes Paket existiert, wird gepflegt und ist im Lockfile fixiert | Hoch |
| 14 | Abhängigkeiten | Prüfung auf bekannte Schwachstellen bestanden; SBOM vorhanden | Mittel |
| 15 | Eingaben | Alle Eingaben serverseitig validiert; Uploads nach Typ und Größe geprüft | Hoch |
| 16 | KI | Modellausgaben gelten als nicht vertrauenswürdig: nie ausgeführt, nie direkt in Abfragen | Hoch |
| 17 | KI | Rate Limits und monatliche Budgetgrenzen für jeden Endpunkt mit Modellaufruf | Hoch |
| 18 | KI | Abgerufene Dokumente und Nutzerinhalte von Anweisungen getrennt; Injection-Tests durchgeführt | Hoch |
| 19 | Web | Nur HTTPS, Security-Header gesetzt, CORS auf eigene Domains beschränkt | Mittel |
| 20 | Betrieb | Backups vorhanden, Wiederherstellung tatsächlich getestet | Hoch |
| 21 | Betrieb | Logs erfassen Sicherheitsereignisse, aber keine Passwörter, Tokens oder unnötigen Personendaten | Mittel |
| 22 | Betrieb | Fehler-Monitoring und Alarme erreichen einen Menschen | Mittel |
| 23 | Datenschutz | Verzeichnis personenbezogener Daten: Speicherort und verarbeitende Anbieter (mit AVV) | Hoch |
| 24 | Datenschutz | Nutzer können Daten exportieren und löschen; Löschen entfernt wirklich | Mittel |
Die Cloud Security Alliance empfiehlt für jede KI-generierte Codebasis ein ähnliches Minimum: statische Codeanalyse, Abhängigkeitsprüfung und Secret-Scanning als Pflichtschritte in der CI; ein Audit der Datenbankregeln; ein separates menschliches Review von Authentifizierungs-, API- und Datencode; eine SBOM; und die Prüfung, dass jedes vorgeschlagene Paket tatsächlich existiert.
So läuft ein Rettungs-Audit in 3–5 Tagen
Tag 1: Erlaubnis, Zugang, Bestandsaufnahme
Zuerst die rechtliche Grundlage: schriftliche Beauftragung und verifizierte Inhaberschaft der App, etwa per DNS-Eintrag oder Meta-Tag der Domain. Dann Lesezugriff auf Repository, Datenbank, Hosting und alle Drittdienste. Ergebnis ist eine Bestandsaufnahme: Komponenten, Datenspeicher, Anbieter, Nutzerrollen und die Daten, die jede Rolle berührt.
Tag 2: automatische Scans
Statische Codeanalyse, Abhängigkeitsprüfung, Secret-Scan des Bundles und der gesamten Git-Historie sowie ein Export aller Datenbankrichtlinien und Storage-Regeln. Automatische Werkzeuge finden das Offensichtliche schnell – und liefern Fehlalarme, die ein Mensch einordnen muss.
Tag 3 (bei größeren Apps auch Tag 4): manuelle Tests
Hier entstehen meist die kritischen Befunde. Mit zwei Testkonten versucht der Prüfer, über jeden Endpunkt und jede Tabelle die Daten des jeweils anderen Kontos zu lesen und zu ändern. Admin-Funktionen werden direkt aufgerufen, KI-Endpunkte mit Injection-Payloads und hohen Anfragevolumina getestet.
Letzter Tag: Bericht und kritische Korrekturen
Jeder Befund erhält eine Schwere, einen Nachweis (Anfrage und Antwort), die geschäftliche Auswirkung in Klartext und einen Lösungsvorschlag. Kritisches – öffentliche Tabellen, offengelegte Schlüssel – wird oft noch am selben Tag behoben, Schlüssel werden rotiert, Tests wiederholt. Der Bericht endet mit einem Maßnahmenplan und einer Aufwandsschätzung für den Rest.
Reparieren, refaktorieren oder neu bauen?
| Was das Audit zeigt | Entscheidung | Typischer Aufwand |
|---|---|---|
| Solides Datenmodell; Probleme sind fehlende Regeln, offene Schlüssel, ungeschützte Routen | An Ort und Stelle reparieren | Tage |
| Datenmodell brauchbar, aber Geschäftslogik und Prüfungen liegen im Browser | Refactoring: echte Server- bzw. API-Schicht ergänzen | Wochen |
| Falsches Datenmodell, keine Tests, dieselbe Logik über viele Masken kopiert, starke Plattformbindung | Kern neu bauen und Daten migrieren | Wochen bis Monate |
Anbieter beziffern Rettungsprojekte auf 50.000–500.000 $ pro App – eine ungeprüfte Spanne aus Marketingmaterial (Creatr). Der eigentliche Kostentreiber ist, wie viel vom Datenmodell sich ändern muss. Gartner erwartet Berichten zufolge, dass 75 % der Unternehmen mit mittleren oder hohen technischen Schulden aus KI-generiertem Code konfrontiert sein werden (Reptile.haus). Je früher das Audit, desto günstiger die Korrektur.
Wenn Sie erst bauen statt reparieren wollen, vermeidet ein strukturierter Sprint die meisten dieser Probleme von Anfang an – siehe MVP in 14 Tagen.
Wenn Sie eine Datenpanne finden
Eine offene Tabelle oder ein geleakter Schlüssel ist ein Vorfall, kein To-do:
- Eindämmen: Zugriffsregeln aktivieren, Schlüssel sperren und rotieren, betroffenen Endpunkt abschalten.
- Beweise sichern: Logs sichern, bevor etwas überschrieben wird.
- Bewerten: Welche Daten, wie viele Personen, wie lange, und hat jemand tatsächlich zugegriffen?
- Melden, falls erforderlich: Nach Art. 33 DSGVO ist eine Verletzung des Schutzes personenbezogener Daten binnen 72 Stunden nach Bekanntwerden der zuständigen Aufsichtsbehörde – in Deutschland meist der Landesdatenschutzbehörde – zu melden, es sei denn, sie führt voraussichtlich nicht zu einem Risiko für die Betroffenen. Die KI-spezifischen Aspekte behandelt unser Leitfaden zu DSGVO für KI-Chatbots.
Typische Fehler
- Verstecken statt schützen. Ein unsichtbarer Button ist keine Zugriffskontrolle.
- Nur die bekannten Tabellen reparieren. Tabellen, die nächsten Monat entstehen, gehen ohne RLS live, wenn die CI das nicht prüft.
- Schlüssel löschen statt rotieren. Ein Schlüssel in der Git-Historie bleibt ein geleakter Schlüssel.
- Einem einzigen Scanner vertrauen. Eingebaute Plattformprüfungen sind nützlich, testen aber nicht, ob Nutzer A die Daten von Nutzer B lesen kann.
- Dasselbe Werkzeug seine eigene Arbeit prüfen lassen. KI-Reviews helfen, aber kritische Pfade braucht ein Mensch, der die Geschäftsregeln versteht.
- Ohne Erlaubnis testen. Auch gut gemeinte Scans fremder Apps können strafbar sein.
- Das Audit als einmalige Sache betrachten. Jede nächste Woche generierte Funktion kann dieselben Probleme wieder einführen.
Fazit
Vibe Coding ist ein legitimer Weg, schnell ein Produkt zu Nutzern zu bringen. Die Risiken sind gut dokumentiert und erstaunlich gleichförmig: Zugriffsregeln, Autorisierung, Secrets, Abhängigkeiten und KI-Endpunkte. Ein fokussiertes Audit findet die kritischen Probleme in wenigen Tagen, und eine Handvoll CI-Prüfungen verhindert ihre Rückkehr. Die laufende Überwachung danach gehört in den KI-Betrieb (AI Ops) – nicht in gute Vorsätze.
Wenn Ihre App bereits Kundendaten speichert, sollten Sie wissen, wo Sie stehen. Unser Build-Team führt Rettungs-Audits durch und setzt die nötigen Korrekturen um. Buchen Sie ein kostenloses 15-Minuten-Audit – wir sagen Ihnen, welche Prüfungen Sie zuerst angehen sollten.