Sicherheit beim Vibe Coding: was Sie prüfen, bevor eine mit KI gebaute App live geht

Sicherheit beim Vibe Coding vor dem Livegang einer App

Eine per Vibe Coding gebaute App, also eine App, die jemand einem KI-Werkzeug beschrieben hat, sollte erst nach einer Sicherheitsprüfung an Kollegen oder Kunden gehen: Die KI schreibt, was der Prompt verlangt, und lässt oft die Zugriffsprüfungen weg, nach denen niemand gefragt hat. Prüfen Sie vor dem Livegang sieben Punkte: Schlüssel und Passwörter im Code und im Browser-Bundle, die Anmeldung, auf dem Server durchgesetzte Zugriffsrechte, Datenbankregeln wie Row-Level Security, jedes von der KI hinzugefügte Paket, Prompt Injection, wenn die App ein Sprachmodell aufruft, und das Logging. Kostenlose Scanner finden Schlüssel im Code und Pakete mit bekannten Lücken, und ein Sprachmodell auf Ihrer eigenen Workstation liest den Code als zweiter Prüfer, ohne dass der Code das Unternehmen verlässt. Anmeldung, Zugriffsrechte und Datenbankregeln brauchen Tests von Hand, über jeden Fund entscheidet ein Mensch, und eine App, die mit Kundendaten im Internet erreichbar ist, braucht zusätzlich einen professionellen Sicherheitstest.

Dieser Leitfaden richtet sich an die Person, die die App mit Dyad, bolt.diy, Lovable, Cursor oder einem Coding-Agenten gebaut hat, und an die IT-Leitung, die sie freigeben soll. Wie solche Apps entstehen, beschreiben unsere Leitfäden zu internen Tools ohne Entwickler und zur selbst gehosteten Lovable-Alternative. Apps auf einer selbst gehosteten Low-Code-Plattform vergleicht unser Leitfaden zu Power-Apps-Alternativen, und Agenturen finden die Seite der Kundenprojekte in unserem Artikel zu Kundenprototypen mit KI.

Warum KI-gebaute Apps eine Sicherheitsprüfung brauchen

Ein typischer Prompt sagt „füge eine Login-Seite hinzu“; selten sagt er „prüfe bei jeder Anfrage, ob dieser Nutzer diesen Datensatz sehen darf“. Die App funktioniert dann in der Demo, und die Lücke zeigt sich erst, wenn jemand Anfragen direkt an das Backend schickt, vorbei an den Schaltflächen der Oberfläche.

Veracode hat mehr als 100 Sprachmodelle mit 80 Programmieraufgaben getestet und am 30. Juli 2025 berichtet, dass die Modelle in 45 Prozent der Fälle Sicherheitslücken einbauten. Bei Cross-Site-Scripting lieferten sie in 86 Prozent der Fälle keinen sicheren Code, bei Log Injection in 88 Prozent, und größere Modelle schnitten nicht deutlich besser ab als kleinere. Die getesteten Modelle sind älter als die heutigen; die Zahlen zeigen das Muster, aktuelle Quoten können abweichen.

Die OWASP Top 10:2025, die Liste von OWASP mit den wichtigsten Risiken für Webanwendungen, setzt Broken Access Control, also fehlerhafte Zugriffskontrolle, auf Platz eins und hält fest: „100% of the applications tested were found to have some form of broken access control“. Vier weitere Kategorien entsprechen direkt den Prüfungen unten: A03 Software Supply Chain Failures, A05 Injection, A07 Authentication Failures und A09 Security Logging and Alerting Failures.

Die Checkliste zur Vibe-Coding-Sicherheit im Überblick

OWASP Top 10:2025 und OWASP Top 10 for LLM Applications 2026, Dokumentation von Vite und Supabase, READMEs der Werkzeuge, gelesen am 30. Oktober 2026; die Auswahl der Prüfungen ist unsere Empfehlung.

Schlüssel und Passwörter im Code, in der Historie und im Browser-Bundle

App-Builder legen API-Schlüssel dorthin, wo der Code sie braucht, und ein Prompt wie „verbinde dich mit dem Zahlungsdienst“ kann mit einem Schlüssel in einer Datei enden, die an jeden Browser ausgeliefert wird. Die Dokumentation von Vite, einem Build-Werkzeug für JavaScript-Webanwendungen, warnt, dass Variablen mit dem Präfix VITE_ nach dem Bundling im clientseitigen Quellcode sichtbar sind („will be exposed in client-side source code after Vite bundling“) und deshalb keine sensiblen Daten wie API-Schlüssel enthalten sollen. Supabase schreibt zu seinem Secret Key: „Never use a secret key in the browser or expose it to customers.“

Gitleaks, ein Secrets-Scanner unter der MIT-Lizenz, prüft mit gitleaks git die gesamte Historie eines Repositorys und mit gitleaks dir beliebige Ordner, also auch den Ordner mit der gebauten App. Sein README beschreibt einen Pre-Commit-Hook, der ein neues Secret vor dem Commit stoppt. Stand Oktober 2026 erklärt das README Gitleaks für „feature complete“, künftige Versionen bringen nur noch Sicherheitskorrekturen („security patches only“). Der Maintainer konzentriert sich inzwischen auf Betterleaks, einen MIT-lizenzierten Scanner, den die Entwickler von Gitleaks pflegen und der zusätzlich online prüfen kann, ob ein gefundener Schlüssel noch gültig ist.

Ein Schlüssel, der einmal committet wurde, bleibt in der Git-Historie, auch wenn die Zeile gelöscht ist. Widerrufen Sie ihn beim Anbieter und lassen Sie einen neuen ausstellen.

Anmeldung und Zugriffsrechte gehören auf den Server

Die Empfehlungen von OWASP zu Broken Access Control sind deutlich: „Access control is only effective when implemented in trusted server-side code or serverless APIs“, „Except for public resources, deny by default“, und Zugriffskontrollen sollen die Zuordnung von Datensätzen zu ihren Eigentümern durchsetzen („enforce record ownership“), statt jedem Nutzer jeden Datensatz zu öffnen. Für eine mit KI gebaute App ergeben sich daraus drei Tests:

1. Jede API-Route und jede Datenbankabfrage prüft, wer fragt. Eine ausgeblendete Schaltfläche in der Oberfläche schützt nichts.
2. Ein Nutzer kann keinen fremden Datensatz öffnen, indem er eine ID in der Adresszeile oder in einer Anfrage ändert. Legen Sie zwei Testkonten an, kopieren Sie eine Anfrage des ersten und senden Sie sie mit der Sitzung des zweiten.
3. Die Anmeldung nutzt den Login-Dienst des Backends oder die vorhandenen Firmenkonten. Eine Passwortprüfung, die die KI selbst geschrieben hat, ist zu ersetzen; OWASP führt Authentication Failures als A07:2025. Mit Firmenkonten verliert eine ausscheidende Person ihren Zugang außerdem an dem Tag, an dem die IT das Konto sperrt.

Offene Datenbanken und Row-Level Security

Viele App-Builder verbinden die App mit einer gehosteten Datenbank, mit der der Browser direkt kommuniziert; die dokumentierten Integrationen von Dyad für Daten und Anmeldung sind zum Beispiel Supabase und Neon. Im Browser liegt dann ein öffentlicher Schlüssel, und zwischen diesem Schlüssel und Ihren Daten stehen nur die Zugriffsregeln der Datenbank selbst. In Supabase sind das Row-Level-Security-Policies (RLS): Regeln in der Datenbank, die festlegen, welche Zeilen ein Nutzer lesen oder ändern darf.

Die Supabase-Dokumentation verlangt, RLS für jede Tabelle in einem über die API freigegebenen Schema einzuschalten („Enable RLS on every table in an exposed schema“), und warnt, dass eine solche Tabelle ohne RLS für jede Rolle mit einem Grant lesbar und beschreibbar ist. Ist RLS eingeschaltet, aber noch keine Policy angelegt, liefert die API mit einem Publishable Key keine Daten („no data is accessible through the API when using a publishable key, until you create policies“). Neue Policies entfernen bereits vorhandene Grants nicht, und der Secret Key nutzt die Rolle service_role, die RLS umgeht.

CVE-2025-48757, veröffentlicht am 30. Mai 2025 mit einem CVSS-3.1-Wert von 9,3, beschreibt unzureichende RLS-Policies in Websites, die ein gehosteter App-Builder erzeugt hat, sodass nicht angemeldete Angreifer beliebige Tabellen lesen oder beschreiben konnten. Der Eintrag ist als umstritten markiert: Nach Ansicht des Anbieters ist jeder Kunde selbst für den Schutz der Daten seiner Anwendung verantwortlich. Prüfen Sie die Policies in jedem Fall selbst. Listen Sie jede Tabelle auf, bestätigen Sie, dass RLS aktiv ist, lesen Sie jede Policy und versuchen Sie, jede Tabelle abgemeldet mit dem öffentlichen Schlüssel zu lesen. Die Supabase-Dokumentation verweist auf Event Trigger, die RLS für jede neue Tabelle einschalten.

Nennen Sie uns Backend und App-Builder Ihrer Apps, und wir schlagen die passenden Prüfwerkzeuge und die Workstation dafür vor.

Pakete, die die KI erfunden hat

Sprachmodelle nennen manchmal Softwarepakete, die es nicht gibt. Eine für das USENIX Security Symposium 2025 angenommene Studie erzeugte mit 16 Modellen 576.000 Codebeispiele in Python und JavaScript. Im Durchschnitt waren mindestens 5,2 Prozent der von kommerziellen Modellen vorgeschlagenen Pakete und 21,7 Prozent der von Open-Source-Modellen vorgeschlagenen erfunden, mit 205.474 verschiedenen erfundenen Namen. Die Autoren nennen das „a novel form of package confusion attack“: Wer einen erfundenen Namen im öffentlichen Paketverzeichnis registriert, bekommt seinen Code bei allen installiert, die dem Vorschlag der KI folgen.

Die Modelle der Studie stammen aus dem Jahr 2024, und der Abstand zwischen offenen und kommerziellen Modellen darin ist ein Grund, jedes Paket zu prüfen, das ein lokales Modell hinzufügt. Prüfen Sie vor jeder Installation, ob ein neues Paket existiert, wer es veröffentlicht und seit wann es verfügbar ist. OSV-Scanner, ein Scanner unter Apache 2.0 auf Basis der Schwachstellendaten von osv.dev, liest danach das Lockfile und listet bekannte Lücken; dabei sendet er Paketnamen und Versionen an osv.dev oder nutzt im Offline-Modus eine lokale Kopie der Datenbank.

Wenn die App ein Sprachmodell aufruft

Wenn die App Tickets zusammenfasst, aus Dokumenten antwortet oder Antworten entwirft, gelten zusätzlich die OWASP Top 10 for LLM Applications. Ihre Ausgabe 2026, veröffentlicht am 3. August 2026, lässt Prompt Injection auf Platz eins, hebt Excessive Agency auf Platz drei und benennt System Prompt Leakage in Hidden Context Exposure um. Vor dem Livegang:

• Schlüssel, Passwörter und Zugriffsregeln gehören nicht in den Systemprompt; gehen Sie davon aus, dass ein Nutzer ihn lesen kann.
• Das Modell handelt mit den Rechten des fragenden Nutzers, nie mit einem Administratorschlüssel, und bevor es eine Mail versendet oder Datensätze ändert, holt die App eine Bestätigung ein.
• Modellausgaben gelten als nicht vertrauenswürdige Eingaben: vor der Anzeige kodieren und nie ungeprüft als Code oder SQL ausführen (LLM10, Improper Output Handling).
• Begrenzen Sie Anfragen je Nutzer, denn Unbounded Consumption steht jetzt auf LLM06.

Unser Artikel zu Prompt Injection und den OWASP Top 10 für LLMs erklärt jedes Risiko mit Beispielen, und unser Leitfaden zur Sicherheit von MCP-Servern behandelt die Werkzeuge, die ein Agent aufruft.

Logging und Fehlermeldungen

OWASP führt Security Logging and Alerting Failures als A09:2025 und Mishandling of Exceptional Conditions als A10:2025. Protokollieren Sie Anmeldungen, fehlgeschlagene Anmeldungen, Rechteänderungen, Exporte und Löschungen mit Zeit und Nutzer, und legen Sie das Log dort ab, wo die App selbst es nicht überschreiben kann. Passwörter, Schlüssel und vollständige personenbezogene Datensätze gehören nicht hinein, und Nutzereingaben werden vor dem Protokollieren bereinigt: Log Injection war in Veracodes Test mit 88 Prozent die schwächste Kategorie. Fehlerseiten zeigen dem Nutzer eine kurze Meldung, die technischen Details bleiben im Log. Logs mit personenbezogenen Daten fallen unter die DSGVO, und Ihr Datenschutz­beauftragter bestätigt, wie lange sie aufbewahrt werden.

Prüfen mit Werkzeugen, die den Code im Haus lassen

Für Secrets, Pakete und riskante Codemuster gibt es kostenlose Werkzeuge, die auf Ihrer eigenen Hardware laufen; Anmeldung, Zugriffsrechte und Datenbankregeln brauchen weiterhin die oben beschriebenen Tests von Hand.

GitHub-READMEs von Gitleaks, Betterleaks, OSV-Scanner, Semgrep und ZAP, Hugging-Face-Karte von Qwen3.8-27B, gelesen am 30. Oktober 2026; Mindestversion von Ollama aus unserem Leitfaden zum Coding-Assistenten (CVE-2026-103663).

Laut Semgrep analysiert das Werkzeug den Code lokal auf Ihrem Rechner oder in Ihrer Build-Umgebung; standardmäßig wird kein Code hochgeladen („by default, code is never uploaded“). Für Ollama entfernt die in seiner FAQ beschriebene Einstellung OLLAMA_NO_CLOUD=1 die Cloud-Modelle und die Websuche, sodass das Prüfmodell keinen Code versehentlich nach außen schickt.

Ein Sprachmodell kommt als Prüfer hinzu, der die App auf einmal liest, so weit sein Kontext reicht. Es sollte lokal laufen, denn der geprüfte Code enthält das Datenbankschema, die Konfiguration und vor der Bereinigung womöglich genau die Schlüssel, die Sie suchen. Auch die eingebaute Sicherheitsprüfung von Dyad nutzt KI; ihre Dokumentation nennt die Funktion experimentell, warnt, dass sie womöglich nicht alle relevanten Sicherheitsprobleme findet („may not catch all relevant security issues“), und empfiehlt, sie zusammen mit anderen Sicherheitsprodukten zu nutzen. Für Apps in GitLab oder GitHub kann das quelloffene Werkzeug PR-Agent jeder Merge-Request-Prüfung einen Sicherheitsabschnitt hinzufügen, wie unser Leitfaden zum selbst gehosteten KI-Code-Review beschreibt. Seine Dokumentation hält lokale Modelle in einer Passage mit Stand Januar 2025 für Experimente und zum Lernen geeignet („experimentation and learning purposes“), für produktive Codeanalyse dagegen nicht („not suitable for production-level code analysis tasks“). Wir haben keine veröffentlichte Messung gefunden, wie viele echte Sicherheitslücken lokale Modelle finden; deshalb bestätigt ein Mensch jeden Fund.

Sie können die Workstation allein bestellen, die Einrichtung von Ollama, Prüfmodell, Gitleaks und OSV-Scanner allein oder beides zusammen: die Workstation mit allem fertig installiert und eingerichtet; schreiben Sie uns, wir schlagen Ihnen die beste Lösung für Ihre Aufgaben und Ihr Budget vor.

Hardware für ein lokales Prüfmodell

Eine Sicherheitsprüfung liest viel Code auf einmal, deshalb braucht das Modell einen langen Kontext: Laut Ollama-Dokumentation sollten Coding-Werkzeuge auf mindestens 64.000 Token eingestellt sein. Der Speicher bestimmt die Konfiguration. Wir rechnen mit unserer Regel für Nutzer je Karte: 90 Prozent des vom Treiber gemeldeten Speichers abzüglich 3 GiB je Karte müssen das Modell und einen Cache für jede gleichzeitig laufende Prüfung fassen. Den Cache rechnen wir in 16 Bit, der Voreinstellung von Ollama; für Qwen3.8-27B sind das rund 8,1 GiB je Sitzung von 128.000 Token, wie unser Leitfaden zur Vibe-Coding-Workstation berechnet.

Unsere Schätzung nach der Regel für Nutzer je Karte mit nutzbarem Speicher von 25,7, 61,5 und 83,0 GiB je Karte, den 4-Bit- (18 GB), 8-Bit- (30 GB) und 16-Bit-Dateien (56 GB) von Ollama und einem 16-Bit-Cache, Stand ollama.com am 30. Oktober 2026; keine Messungen.

Auf der Einstiegsstufe lässt das 4-Bit-Modell (16,8 GiB) 8,9 GiB frei, genug für eine Prüfung mit 128.000 Token. Ollama beantwortet je Modell eine Anfrage nach der anderen, bis OLLAMA_NUM_PARALLEL erhöht wird, und jeder parallele Platz reserviert den vollen Kontext; die Einrichtung setzt beides für die Prüfungen in der Tabelle. Eine RTX PRO 6000 Workstation Edition oder Max-Q fasst auch Qwens FP8-Checkpoint in vLLM mit sechs Prüfungen von 128.000 Token, mit einem FP8-Cache mit 13. Wenn ein Entwicklungsteam eine Prüfung bei jedem Merge Request und Coding-Agenten auf derselben Hardware möchte, wandert das Modell auf einen Rack-Server, wie unser Leitfaden zum Server für Coding-Agenten dimensioniert. Die Scanner brauchen keine GPU; sie laufen auf dem Prozessor derselben Maschine.

Einen Anhaltspunkt für das Tempo gibt der Test von StorageReview vom 14. Oktober 2026: Qwen3.8-27B im NVFP4-Format von NVIDIA, betrieben mit vLLM 0.27.1, schrieb bei einer einzelnen Anfrage auf jeder Karte, auf der es lief, zwischen 17 und 22 Token pro Sekunde, von der RTX PRO 4500 Blackwell Server Edition und einer L40S bis zu einer RTX PRO 6000 Blackwell Workstation Edition. Bei diesem Tempo dauert ein Prüfbericht von 2.000 Token nach unserer Rechnung etwa anderthalb bis zwei Minuten. Das Einlesen einer großen Codebasis vor der Antwort kostet zusätzlich Zeit, abhängig von ihrer Länge und der Karte; eine veröffentlichte Zahl für diese Aufgabe haben wir nicht gefunden.

Nach unserer Schätzung (Karte, ein 350-W-Prozessor und 15 Prozent für den Rest) zieht eine Workstation mit einer RTX PRO 4500 unter Volllast etwa 0,6 kW, mit einer RTX PRO 5000 etwa 0,75 kW und mit einer RTX PRO 6000 Workstation Edition etwa 1,1 kW, jeweils an einem normalen 230-V-Stromkreis. Ein Server mit zwei RTX PRO 6000 Server Edition zieht etwa 1,8 kW und gehört in einen Serverraum.

Eine Freigaberegel für KI-gebaute Apps

Jemand muss die Entscheidung verantworten. Eine kurze Regel in der KI-Nutzungsrichtlinie des Unternehmens kann Apps danach einordnen, wer sie nutzt und was sie enthalten.

Unsere Empfehlung.

Mit KI geschriebener Code wirft auch Fragen zu Lizenzen und Rechten auf, die unser Artikel zur Richtlinie für KI-Coding-Assistenten behandelt, und unsere Sicherheitsfragen für die Geschäftsführung helfen, wenn das Prüfmodell selbst auf einem Firmenserver läuft.

Senden Sie uns die Zahl der Personen, die Apps bauen, und ihre Werkzeuge; wir schlagen die passende Workstation für die Prüfung vor.

FAQ