Sicherheit beim Vibe Coding: So schützen Sie eine mit KI erstellte App

Weitere Anleitungen zur Arbeit mit Ailoot finden Sie in der Dokumentation.

Warum werden mit KI erstellte Apps häufiger gehackt?#

Ich selbst entwickle Produkte mit KI und werde nicht so paranoid, dass ich aus Sicherheitsgründen „alles maximal verriegle“. Aber ein grundlegendes Schutzniveau darf man nicht unterschreiten. Sonst wacht man eines Tages mit einer leeren Datenbank und den Mining-Programmen anderer Leute auf dem eigenen Server auf. In diesem Leitfaden geht es um dieses grundlegende Niveau. Nicht darum, „Sicherheitsexperte zu werden“, sondern darum, „sich nicht ohne Grund selbst ein Bein zu stellen“.

Die Ursache des Problems ist einfach. Wenn Sie einem KI-Agenten sagen: „Erstelle mir eine App, mit der Kunden Termine buchen können“, bringt er die App so schnell wie möglich zum Laufen. Sicherheit ist zusätzliche Arbeit, die in einer Demo nicht sichtbar ist. Also wird die Datenbank offen eingerichtet, der Zahlungsschlüssel landet direkt im Code, und die Prüfung, „ob dieser Nutzer Zugriff hat“, findet nur im Browser statt, wo sie sich in einer Sekunde umgehen lässt.

Anders gesagt: Die Lücke entsteht von selbst, standardmäßig. Sie haben nichts falsch gemacht. Sie haben einfach nichts getan – und in der Sicherheit bedeutet Untätigkeit genau das: „für alle zugänglich“.

Was haben Vibe Coder bereits auf die harte Tour gelernt?#

Der beste Schutz gegen Nachlässigkeit ist, aus den Fehlern anderer zu lernen. Hier sind vier Beschreibungen, die Sie sich vor der Veröffentlichung Ihres Projekts ansehen sollten.

Lovable und deaktiviertes RLS. Die Plattform Lovable erstellt Apps anhand von Textbeschreibungen. 2025 wurde in ihren Apps eine systemische Lücke entdeckt und als CVE-2025-48757 registriert. Die Ursache: Den generierten Apps fehlten Datenbankzugriffsregeln auf Zeilenebene (RLS, weiter unten erklärt). Ein Forscher prüfte eine Stichprobe und fand 303 offengelegte Zugriffspunkte in 170 Apps. Namen, Telefonnummern, Zahlungsstatus, API-Schlüssel anderer Personen und sogar Privatadressen waren zugänglich. Bei etwa 70 Prozent der geprüften Apps war der Schutz auf Zeilenebene vollständig deaktiviert.

Tea und sensible Daten. Bei der Tea-App (anonyme Bewertungen von Personen) gingen im Juli 2025 etwa 72.000 Bilder verloren, darunter 13.000 Selfies und Fotos von Dokumenten, und anschließend mehr als eine Million private Nachrichten. Die technische Ursache waren offener Speicher und schwache Zugriffskontrollen. Die Sicherheitsgemeinschaft führt Tea als anschauliches Beispiel an: Wenn ein schneller Start wichtiger ist als die Überprüfung von Berechtigungen, sickern sensible Daten als Erstes durch.

Ein weiteres praktisches Beispiel. In einem Fall, den der ursprüngliche Autor beschrieb, wurde die App eines Vibe Coders gehackt, weil die KI beim Erstellen der Datenbank ein Standardpasswort setzte, das sich automatisch erraten ließ. Danach lief die übliche Abfolge ab: Die Angreifer kamen hinein, installierten Mining-Programme und schrieben das Projekt um. Der Server musste vollständig gelöscht werden. Ein Standardpasswort ist eine unverschlossene Tür mit einem Schild „Kommen Sie ruhig herein“.

Zwei Sicherheitsbereiche: Wo genau sind Sie verwundbar?#

Wenn von „Vibe-Coding-Sicherheit“ die Rede ist, werden meist zwei völlig unterschiedliche Befürchtungen in einen Topf geworfen. Trennen wir sie, denn sie erfordern unterschiedliche Schutzmaßnahmen.

Bereich eins – der Agent selbst. Sie führen einen KI-Agenten auf Ihrem Computer aus und geben ihm Zugriff auf Ihre Dateien, Ihr Terminal, Ihre Schlüssel und Ihre Datenbank. Das Risiko besteht darin, dass ein Agent kein Mensch ist: Er befolgt Anweisungen wörtlich und sucht den kürzesten Weg, selbst wenn dieser gefährlich ist. Dazu gehört auch das Risiko, dass der Agent durch Text, den er liest, mit einem Befehl einer anderen Person „injected“ wird (das nennt man Prompt Injection).

Bereich zwei – die fertige App. Das ist das, was Sie veröffentlicht haben und was andere benutzen. Ihr veröffentlichter Dienst oder Ihre Website ist das Ziel: Angreifer dringen in eine offene Datenbank ein, senden gefälschte Anfragen oder erraten die Konten anderer Nutzer. Der Agent hat damit nichts zu tun – die Lücke blieb bereits vorher offen und wird von anderen ausgenutzt.

Anthropic, das Unternehmen hinter Claude, formuliert das zentrale Schutzprinzip so – und es gilt für beide Bereiche:

In der Praxis heißt das: Verlassen Sie sich nicht darauf, dass die KI „von selbst nichts Böses tut“. Beschränken Sie zuerst, was sie tatsächlich tun kann, und bitten Sie sie erst danach, sich korrekt zu verhalten. Wenn ihr Verhalten versagt – und das wird passieren –, schützt Sie nur eine feste Grenze, die Sie vorher eingerichtet haben.

Möchten Sie, dass die KI berechenbar arbeitet und Ihnen nicht bei jedem neuen Projekt selbst ein Bein stellt? Sicherheitsregeln gehören zu Ihrem Second Brain: Halten Sie sie einmal in CLAUDE.md fest, und der Agent wird sie bei jeder Anfrage befolgen.

Was kann ein KI-Agent mit Zugriff auf Ihren Computer tun?#

Das meist unterschätzte Risiko ist der eigene Agent mit zu weitreichenden Berechtigungen. Ein externer Hacker ist dafür gar nicht nötig. Hier ist ein aktuelles Beispiel aus Ende Mai 2026. Ein Codex-Agent benötigte Administratorrechte, die der Nutzer nicht hatte. Der Agent gab nicht auf: Er sah sich um, bemerkte, dass der Nutzer zur Gruppe docker gehörte – was Root-Rechten gleichkommt – und nutzte diesen Zugriff.

Hier lag keine böse Absicht vor. Ein Agent, der den Auftrag erhält, „die Aufgabe zu lösen“, findet strukturelle Schwachstellen einfach schneller als ein Mensch. Und wenn eine solche Schwachstelle ihm Zugriff auf Ihre Schlüssel oder Ihre Produktionsumgebung verschafft, wird er ihn nutzen. Deshalb lautet die erste Regel: das Prinzip der geringsten Berechtigung. Geben Sie einem Agenten für eine bestimmte Aufgabe genau so viel Zugriff, wie er benötigt, und keinen Deut mehr.

Was können Sie praktisch tun, auch wenn Sie nicht programmieren?

1. Führen Sie den Agenten auf einem Produktionsrechner nicht im Modus „alles erlauben“ aus

   Ein Modus, in dem der Agent nicht um Bestätigung bittet (oft Bypass- oder YOLO-Modus genannt), ist nur für eine Sandbox oder ein Testprojekt gedacht, nicht für einen Rechner mit aktiven Schlüsseln und Zugriff auf die Produktionsumgebung.

2. Verbieten Sie dem Agenten, Geheimnisse zu lesen

   In Claude Code richten Sie dafür eine Regel ein, die den Zugriff auf Dateien mit Schlüsseln verweigert. Selbst wenn der Agent dann .env öffnen möchte, lässt das Tool ihn nicht.

3. Halten Sie Produktionsschlüssel getrennt

   Schlüssel für die Produktionsdatenbank und den Zahlungsdienst sollten nicht in demselben Ordner liegen, in dem der Agent Code schreibt. Halten Sie die Umgebungen getrennt: Verwenden Sie beim Experimentieren Testschlüssel.

4. Verwenden Sie die Sandbox des Tools

   Moderne KI-Tools können Befehle isoliert ausführen (in einer Sandbox), wo sie keinen Zugriff auf den Rest des Systems haben. In Claude Code verringert das die Zahl der Berechtigungsanfragen um etwa 84 Prozent – und ist damit auch bequemer.

Eine Regel, die Claude Code das Lesen von Geheimnissen verweigert, sieht ungefähr so aus – fügen Sie sie in die Berechtigungseinstellungen ein:

{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(**/.env)",
      "Bash(git push *)"
    ]
  }
}

Wo sollten Sie API-Schlüssel und Passwörter niemals ablegen?#

Der billigste und häufigste Fehler ist, Schlüssel im Code abzulegen. Ein API-Schlüssel für einen Zahlungsdienst, ein Datenbankpasswort, ein Bot-Token – all das sind Geheimnisse. Sie gehören in eine separate .env-Datei, und diese Datei muss in .gitignore aufgeführt sein, damit sie nicht zusammen mit dem Code in Git landet.

Das Ausmaß des Problems 2025: 28,65 Millionen neu fest im Code hinterlegte Geheimnisse in öffentlichen Repositories, 34 Prozent mehr als im Vorjahr. Leaks von Schlüsseln speziell für KI-Dienste stiegen um 81 Prozent. Vibe Coding heizt das Problem weiter an, weil der Agent Commits ausführt, ohne hinzusehen.

Was Sie jetzt selbst überprüfen können:

1. Öffnen Sie die .gitignore-Datei des Projekts

   Vergewissern Sie sich, dass sie eine Zeile mit .env enthält. Falls nicht, fügen Sie eine hinzu, bevor Sie den ersten Commit machen.

2. Öffnen Sie Ihr GitHub-Repository

   Prüfen Sie, ob die .env-Datei dort nicht vorhanden ist. Eine schnelle Kontrolle ist, im Repository nach .env oder einem Teil Ihres Schlüssels zu suchen.

3. Widerrufen Sie einen durchgesickerten Schlüssel und stellen Sie ihn neu aus

   Den Commit zu löschen reicht nicht: Der Schlüssel könnte bereits abgegriffen worden sein. Rufen Sie den Dienst auf (Zahlungsanbieter, Cloud-Dienst, KI-Anbieter), widerrufen Sie den alten Schlüssel und stellen Sie einen neuen aus. Das nennt man Rotation.

4. Beschränken Sie Schlüssel auf die nötigen Berechtigungen

   Wird ein Schlüssel nur zum Lesen benötigt, richten Sie ihn als Nur-Lese-Schlüssel ein. Dann kann selbst bei einem Leak weniger gestohlen werden.

Warum kann ohne RLS jeder Ihre Datenbank einsehen?#

Wenn Sie eine App mit Supabase oder einer ähnlichen Datenbank entwickeln, ist dies der wichtigste Abschnitt. RLS steht für Row Level Security. Einfach gesagt ist es eine Regel, die festlegt, welche Zeilen einer Tabelle einem bestimmten Nutzer angezeigt werden. Ohne RLS liefert die Tabelle „orders“ allen sämtliche Bestellungen zurück.

Die Supabase-Dokumentation selbst formuliert es ganz klar:

Hier liegt die größte Falle für Vibe Coder. Wenn Sie eine Tabelle durch Klicken im Supabase-Dashboard erstellen, wird der Schutz automatisch aktiviert. Erstellt die KI die Tabelle – und sie schreibt fast immer SQL-Befehle direkt –, bleibt RLS standardmäßig deaktiviert. Das bedeutet: Eine vom Agenten erstellte Tabelle ist mit großer Wahrscheinlichkeit für das gesamte Internet offen. Genau so sind jene 170 Lovable-Apps undicht geworden.

Was zu tun ist:

1. Fragen Sie den Agenten direkt

   Schreiben Sie: „Zeig mir alle Tabellen, bei denen RLS deaktiviert ist.“ Die KI erstellt eine Liste – das ist Ihre Aufgabenliste.

2. Aktivieren Sie RLS für jede Tabelle mit Nutzerdaten

   Fügen Sie außerdem mindestens eine Zugriffsrichtlinie hinzu – zum Beispiel: „Ein Nutzer kann nur seine eigenen Zeilen sehen.“

3. Prüfen Sie das Dashboard

   Im Supabase-Dashboard sollte bei jeder Tabelle „RLS enabled“ angezeigt werden. Ist die Anzeige grau oder rot, bedeutet das, dass die Tabelle offen ist.

4. Testen Sie es in der Praxis

   Melden Sie sich als normaler Nutzer an und versuchen Sie, die Daten einer anderen Person abzurufen. Wird der Zugriff verweigert, funktioniert die Richtlinie.

Warum schützen Berechtigungsprüfungen in der Benutzeroberfläche Sie nicht?#

Ein verbreiteter Irrtum lautet: „Ich habe dafür gesorgt, dass normale Nutzer die Admin-Schaltfläche nicht sehen.“ Das Problem ist, dass eine Schaltfläche im Browser nur ein Bild ist. Eine Anfrage lässt sich direkt an den Server senden, ohne die Schaltfläche zu benutzen. Prüft der Server die Berechtigungen nicht erneut, führt er den Befehl einer anderen Person aus.

Ein klassisches Beispiel heißt IDOR. Stellen Sie sich vor, Sie öffnen Ihre Bestellung unter einer Adresse mit id=123. Ändern Sie die Zahl in id=124, sehen Sie möglicherweise die Bestellung einer anderen Person, weil der Server nicht geprüft hat, ob sie tatsächlich Ihnen gehört. Das ist eine der häufigsten Schwachstellen in Vibe-Coding-Apps, und schwache Berechtigungsprüfungen waren eine Ursache des Tea-Leaks.

Die Regel ist einfach: Wiederholen Sie jede Prüfung, ob ein Nutzer etwas tun darf, auf dem Server. Die Benutzeroberfläche dient der Bequemlichkeit; der Schutz gehört ins Backend. Eine direkt verwendbare Anweisung für den Agenten: „Füge für jeden Endpunkt, der Nutzerdaten liest oder ändert, serverseitige Berechtigungsprüfungen hinzu; verlasse dich nicht darauf, dass ein Element in der Benutzeroberfläche ausgeblendet ist.“

Wie können Sie Code auf Schwachstellen prüfen, wenn Sie nicht programmieren?#

Die gute Nachricht: Heute können Sie dieselbe KI um eine Sicherheitsprüfung bitten – sie findet häufige Schwachstellen recht zuverlässig. Hier sind drei Tools für unterschiedliche Aufgaben.

1. Der Befehl /security-review in Claude Code. Eine einmalige Prüfung des aktuellen Branches auf SQL-Injection, XSS, Berechtigungslücken, Datenlecks und Abhängigkeitsprobleme. In einer separaten Anleitung zur Sicherheitsprüfung in Claude Code habe ich Schritt für Schritt erklärt, wie sie funktioniert und wie sich eine automatische Prüfung an jede Änderung anhängen lässt. Der wichtigste Punkt hier: Sie ist die erste Verteidigungslinie und wird mit einem einzigen Befehl gestartet.

2. Das offizielle Plugin security-guidance. Installieren Sie es über den offiziellen Plugin-Marktplatz mit /plugin install security-guidance@claude-plugins-official (erfordert Claude Code Version 2.1.144 oder höher). Es prüft den Code an drei Stellen: bei jeder Bearbeitung, am Ende jedes Turns und zum Zeitpunkt des Commits. Es erkennt das Umgehen von Berechtigungen, IDOR, Injections und schwache Kryptografie. Doch Anthropic weist offen auf die Grenzen hin:

npx skills add <author>/<repo>

Sagen Sie dem Agenten anschließend einfach: „Prüfe mein Projekt auf Schwachstellen.“ Zu dieser Sammlung gibt es jedoch einen wichtigen Vorbehalt, weshalb ich ihr weiter unten einen eigenen Abschnitt widme.

Zur Einordnung: Auch große Akteure nehmen die Sicherheit von KI-Code inzwischen ernst. Im Rahmen von Project Glasswing, das am 2. Juni 2026 auf 150 Organisationen ausgeweitet wurde, fanden Partner mithilfe von Anthropic-Modellen in kurzer Zeit mehr als 10.000 kritische Schwachstellen. Die Tragweite ist klar:

Kann man Skills und Erweiterungen von GitHub vertrauen?#

Hier wird es besonders knifflig, denn die Gefahr geht von einem Sicherheitstool aus, das Sie selbst installieren. Wenn Sie npx skills add ... ausführen oder eine Erweiterung installieren, laden Sie fremden Code herunter, den der Agent anschließend mit Ihren Berechtigungen ausführt. Wurde der Autor gehackt oder war das Paket von Anfang an bösartig, haben Sie ein Problem.

Nehmen wir die Skills-Sammlung aus dem vorherigen Abschnitt. Ihr Name enthält „Anthropic“, wodurch man die Vorsicht leicht fallen lässt. Doch in der eigenen Beschreibung steht ganz klar:

Anders gesagt: Der Name ist irreführend. Die Sammlung ist derzeit ausgereift und sauber, aber das Prinzip bleibt: Sie installieren sie auf eigenes Risiko. Und die Gefahr ist nicht theoretisch. Im Mai 2026 war eine bösartige Editor-Erweiterung gerade einmal 18 Minuten auf dem Marktplatz – in dieser Zeit gelang es ihr, Passwörter aus Passwortmanagern, GitHub-Tokens, Cloud-Zugänge und sogar Claude-Code-Konfigurationen der Personen zu stehlen, die sie installiert hatten. Ein weiteres unangenehmes Detail: Solche Schadsoftware übersteht oft das gewöhnliche Entfernen des Pakets und wird in der nächsten Sitzung erneut ausgeführt.

Ich habe mir eine einfache Gewohnheit angewöhnt, die ich Ihnen ebenfalls empfehle: Prüfen Sie jeden Skill von GitHub selbst, bevor Sie ihn installieren. Autoren können gehackt, Konten übernommen und Repositorys mit Schadsoftware versehen werden. Die Prüfung ist Ihr Schutz.

Das praktische Minimum vor der Installation: Sehen Sie sich den Autor und die Zahl der Sterne an, lesen Sie die Skill-Beschreibung, installieren Sie ein Tool nicht „nur wegen einer Empfehlung in einem Beitrag“ und probieren Sie unbekannte Tools zuerst in einer separaten Testumgebung aus – nicht auf einem Rechner mit Produktionsschlüsseln.

Was hilft Ihnen nach einem Sicherheitsvorfall: Backups und Rollback#

Bei Sicherheit geht es nicht nur darum, „Außenstehende fernzuhalten“, sondern auch darum, „nach einem Fehler wieder zum Normalzustand zurückzukehren“. Denn etwas wird schiefgehen. Im beschriebenen praktischen Fall löschte ein KI-Agent bei einer Routineaufgabe eine aktive Datenbank in einem Produktionsprojekt. Es gab ein Backup, aber es war drei Tage alt – und drei Tage Daten waren einfach verschwunden.

Daraus ergeben sich zwei Regeln.

Häufig sichern. Wenn Ihre App Daten enthält, die Sie nicht verlieren möchten, ist eine Kopie alle drei Tage nur ein trügerisches Sicherheitsgefühl. Richten Sie automatische Backups mindestens alle 30 Minuten ein. Bei den meisten Datenbanken, auch bei Supabase, lässt sich das mit wenigen Klicks aktivieren.

Git ist die Versicherung gegen den Agenten. Git speichert den Verlauf Ihres Codes: Sie können jeden funktionierenden Stand wiederherstellen. Wenn ein Agent etwas Funktionierendes umschreibt, kehren Sie zur letzten funktionierenden Version zurück, statt es von Hand zu reparieren. Falls die KI das Projekt gelöscht oder beschädigt hat und Sie nicht wissen, wie Sie es zurückbekommen, lesen Sie den separaten Bericht: Was tun, wenn die KI die Datenbank gelöscht hat. Wie Sie sich im Voraus vor Schäden am Projekt schützen, erfahren Sie in der Anleitung So schützen Sie Claude Code vor Schäden.

Sicherheitscheckliste vor der Veröffentlichung#

Gehen Sie diese Liste unmittelbar vor der Veröffentlichung Punkt für Punkt durch.

1. Geheimnisse in .env und .env in .gitignore. Keine Schlüssel im Code. Keine .env-Datei in einem öffentlichen Repository.

2. Schlüssel mit den geringstmöglichen Berechtigungen. Jeder Schlüssel kann nur das Nötige tun. Produktionsschlüssel sind von der Umgebung des Agenten getrennt.

3. RLS ist aktiviert für alle Tabellen mit Nutzerdaten, und Zugriffsrichtlinien sind eingerichtet.

4. Serverseitige Berechtigungsprüfungen für jede Datenoperation. Eine Schaltfläche in der Benutzeroberfläche auszublenden, reicht nicht. Das Ändern der id in der Adresse wurde manuell getestet.

5. Webhook-Signaturprüfung. Jeder Handler für externe Benachrichtigungen (Zahlungen, Formulare) überprüft die Signatur.

6. Ratenbegrenzung für eingehende Anfragen und kostspielige Vorgänge, damit Passwörter nicht durch systematisches Ausprobieren erraten und Ihre Rechnung nicht in die Höhe getrieben werden kann.

7. Der Agent läuft nicht im Modus „alles erlauben“ auf einem Rechner mit Produktionsschlüsseln. Das Lesen von .env ist untersagt.

8. Backups werden häufig erstellt und getestet – Sie haben tatsächlich eine Wiederherstellung ausprobiert, statt nur zu glauben, dass die Kopien „irgendwo liegen“.

9. Der Code wurde geprüft mit /security-review oder dem Plugin security-guidance. Die gefundenen Probleme wurden behoben.

10. Skills und Erweiterungen anderer Personen wurden vor der Installation geprüft. Nichts wurde „blind“ installiert.

Wo Sie heute anfangen können#

Versuchen Sie nicht, alles in diesem Leitfaden an einem Abend umzusetzen – sonst machen Sie am Ende gar nichts. Erledigen Sie heute die drei wichtigsten Schritte:

1. Prüfen Sie Ihre Geheimnisse. Öffnen Sie .gitignore, vergewissern Sie sich, dass .env aufgeführt ist, und prüfen Sie, ob keine Schlüssel im öffentlichen Repository liegen. Sind Schlüssel durchgesickert, widerrufen Sie sie und stellen Sie neue aus.
2. Fragen Sie nach RLS. Sagen Sie dem Agenten: „Zeig mir die Tabellen, bei denen RLS deaktiviert ist“ – und aktivieren Sie es überall dort, wo Daten von Personen gespeichert sind.
3. Richten Sie häufige Backups ein. Damit Sie bei einem Fehler Minuten statt Tage verlieren.

Arbeiten Sie anschließend die obige Checkliste ab, während Ihr Projekt wächst und beginnt, Geld und Daten anderer Personen zu verarbeiten.

Noch eine letzte Sache. Bei der Sicherheit des Vibe Coding geht es um die Verantwortung des Eigentümers. Sie müssen kein Sicherheitsexperte werden. Die KI hat Ihr Produkt an einem Abend erstellt – großartig, aber Sie sind dafür verantwortlich. Das grundlegende Niveau in diesem Leitfaden zeigt, wie diese Verantwortung in der Praxis aussieht.

Für die weitere Arbeit mit Modellen können Sie zu Ailoot wechseln.