So sichern Sie eine Vibe-Coding-App ab, bevor Sie sie teilen
Kurze Antwort
Bevor Kollegen eine App nutzen, die Sie mit KI gebaut haben, prüfen Sie zuerst vier Dinge: Niemand kommt an einem Firmen-Login vorbei, nur Konten Ihrer Firma kommen rein, im Code, der im Browser läuft, stehen keine Schlüssel, und die Datenbank lässt sich nicht lesen, ohne durch die App zu gehen. Danach prüfen Sie, wer darin was tun darf und wem sie gehört, wenn Sie gehen.
Die meisten Datenlecks bei KI-gebauten Apps sind keine raffinierten Angriffe. Es sind offene Türen: ein öffentlicher Link, eine Datenbank mit abgeschalteten Regeln, ein Schlüssel in der Seite. Diese Checkliste ist für die Person, die die App gebaut hat, und für die IT, die sie prüft. Jeder Punkt sagt, was schiefgeht, wie Sie es in einfachen Worten prüfen, und was TeamOnly übernimmt und was noch bei Ihnen liegt.
Zuletzt aktualisiert Geschrieben von TeamOnly. Wir hosten interne Apps, die mit KI gebaut wurden, und jeder Punkt sagt ehrlich, wo wir helfen und wo nicht.
01Warum das wichtig ist
Was bei KI-gebauten Apps schiefgeht
KI-Tools sind gut darin, eine App zum Laufen zu bringen. Weniger sorgfältig sind sie dabei, für wen sie sonst noch läuft. Drei Befunde aus den letzten zwei Jahren zeigen das Muster.
380.000
öffentlich erreichbare Assets fand das Sicherheitsunternehmen Red Access im Mai 2026 auf Lovable, Base44, Netlify und Replit. Etwa 5.000 davon enthielten sensible Firmendaten, und viele waren bei Google indexiert.
170 von 1.645
im März 2025 geprüften Lovable-Apps ließen jeden ohne Anmeldung Daten in ihrer Supabase-Datenbank lesen oder ändern, weil die Zugriffsregeln der Datenbank fehlten oder falsch waren (CVE-2025-48757).
205.474
erfundene Paketnamen schlugen 16 KI-Modelle in 576.000 Codebeispielen vor, so eine Studie von 2025. Angreifer können Pakete unter diesen Namen veröffentlichen und warten, bis jemand sie installiert.
Für nichts davon brauchte es einen raffinierten Angreifer. Die Türen standen offen. Das ist die gute Nachricht: Offene Türen lassen sich leicht finden, und dafür müssen Sie keinen Code lesen.
Gehen Sie sie der Reihe nach durch. Die ersten halten Fremde draußen, die späteren finden Fehler innerhalb der Firma.
Nichts lädt vor einem Firmen-Login
Was schiefgeht
KI-Tools bauen die Anmeldeseite oft als eine Seite der App. Der Rest der App und ihre API antworten trotzdem jedem, der diese Seite überspringt oder die API direkt aufruft. Red Access fand Firmen-Apps, die jedem Admin-Zugriff gaben, der die Adresse erreichte.
Selbst prüfen
Öffnen Sie die App in einem privaten Browserfenster. Sie sollten eine Anmeldeseite sehen und sonst nichts. Fragen Sie dann Ihr KI-Tool: „Liste jede API-Route auf und sag mir, welche ohne Anmeldung funktionieren.“ Die Antwort sollte lauten: keine.
Bei TeamOnly
Übernommen. Jede Anfrage an jede App wird geprüft, bevor irgendein Code von Ihnen läuft, auch API-Aufrufe, die ohne Sitzung eine 401 bekommen. Es gibt keine Einstellung, um eine App öffentlich zu machen.
Nur Konten Ihrer Firma kommen rein
Was schiefgeht
„Mit Google anmelden“ lässt standardmäßig jedes Google-Konto rein, auch ein privates Gmail. Die Google-Einstellung hd grenzt nur die Kontoauswahl ein, und Google warnt, sich nicht darauf zu verlassen, weil die Anfrage verändert werden kann. Die Domain muss auf dem Server geprüft werden.
Selbst prüfen
Versuchen Sie, sich mit einem privaten Gmail- oder Outlook-Konto anzumelden. Sie sollten abgewiesen werden. Fragen Sie Ihr KI-Tool, wo der Server die E-Mail-Domain prüft und ob er das signierte Token von Google prüft oder einen Wert, den der Browser geschickt hat.
Bei TeamOnly
Übernommen. Kollegen melden sich mit ihrem Google- oder Microsoft-Firmenkonto an oder mit einem Code an ihre geschäftliche E-Mail. Die Domain im verifizierten Anmelde-Token wird mit den Domains Ihrer Firma abgeglichen, private Konten werden abgelehnt.
Nur die richtigen Personen in der Firma
Was schiefgeht
Eine App mit Gehältern, Beurteilungen oder Kundendaten wird mit der ganzen Firma geteilt, weil das die Voreinstellung war. Oder die KI baut eine eigene Erlaubnisliste in den Code, die niemand pflegt.
Selbst prüfen
Fragen Sie sich: Soll jeder in der Firma diese Daten sehen? Wenn nicht, schreiben Sie die Namen der Personen auf, die sie sehen sollen, und prüfen Sie, dass jemand außerhalb dieser Liste abgewiesen wird.
Bei TeamOnly
Übernommen, Sie entscheiden. Zugriff hat die ganze Firma oder eine Namensliste, festgelegt im Dashboard oder mit npx teamonly access only priya@acme.com. Das wird bei jeder Anfrage geprüft, wer entfernt wird, ist also innerhalb einer Minute draußen.
Kein öffentlicher Link, nicht in Suchergebnissen
Was schiefgeht
Manche App-Builder veröffentlichen unter einer öffentlichen Adresse, wenn Sie nicht privat wählen. Öffentliche Apps werden gefunden: Laut Red Access waren viele der offen liegenden Firmen-Apps bei Google und anderen Suchmaschinen indexiert.
Selbst prüfen
Suchen Sie bei Google nach site: gefolgt von der Adresse Ihrer App. Prüfen Sie die Sichtbarkeitseinstellung des Projekts auf der Plattform, mit der Sie es gebaut haben. Steht dort öffentlich, ändern Sie das vor allem anderen.
Bei TeamOnly
Übernommen. Apps liegen unter yourapp.yourcompany.teamonly.app hinter der Anmeldeseite. Jede Antwort, auch die Anmeldeseite, sagt Suchmaschinen, dass sie nicht indexiert werden soll, und die Anmeldeseite zeigt nur den Namen der App und die Wege zur Anmeldung.
Keine Schlüssel im Code, der im Browser läuft
Was schiefgeht
KI-Tools schreiben API-Schlüssel in den React-Code oder in Variablen, die mit VITE_ oder NEXT_PUBLIC_ beginnen. Alles, was an den Browser geht, kann jeder lesen, der die App öffnet. Supabase sagt, sein secret key dürfe nie in einem Browser stehen, weil er jede Datenbankregel umgeht.
Selbst prüfen
Fragen Sie Ihr KI-Tool: „Steht ein Schlüssel, Token oder Passwort im Frontend-Code, in einer VITE_-Variable oder in einer eingecheckten .env-Datei?“ Öffnen Sie im Browser die Entwicklertools und durchsuchen Sie die geladenen Dateien nach key, secret und sk_. War ein Schlüssel je offen sichtbar, ändern Sie ihn bei dem Dienst, der ihn ausgestellt hat.
Bei TeamOnly
Teilweise übernommen. Schlüssel werden mit npx teamonly secrets set NAME außerhalb des Codes gespeichert, und nur der Servercode Ihrer App kann sie lesen. Die Anweisungen, die TeamOnly hinzufügt, sagen Ihrem KI-Tool, nie VITE_-Schlüssel zu verwenden. Nichts hindert Sie daran, selbst einen Schlüssel in den Code einzufügen, prüfen Sie also trotzdem.
Die Datenbank lässt sich nicht an der App vorbei lesen
Was schiefgeht
Bei Supabase und ähnlichen Diensten spricht der Browser direkt mit der Datenbank, und Zugriffsregeln (Row Level Security) entscheiden, was er sehen darf. Sind diese Regeln aus oder falsch, kann jeder mit dem öffentlichen Schlüssel ganze Tabellen lesen oder ändern. Das war der Befund bei Lovable.
Selbst prüfen
Öffnen Sie in Supabase Advisors, dann Security Advisor. Jeder Fehler „RLS disabled in public“ bedeutet eine Tabelle, die jeder lesen kann. Dass eine Regel existiert, reicht nicht: Melden Sie sich als normale Kollegin oder normaler Kollege an und versuchen Sie, den Datensatz einer anderen Person zu öffnen.
Bei TeamOnly
Für Außenstehende übernommen. Die Datenbank jeder App hat keine eigene Adresse im Internet. Sie ist nur über den Servercode Ihrer App erreichbar, nach der Anmeldung. Welche Zeilen jede angemeldete Person sehen darf, muss der Code Ihrer App weiterhin richtig regeln (siehe Prüfung 8).
Die Daten jeder App getrennt
Was schiefgeht
Mehrere Apps teilen sich eine Datenbank oder einen Speicher-Bucket, weil das schneller ging. Dann öffnet ein Schlüssel oder ein Fehler in einer App alle.
Selbst prüfen
Fragen Sie sich: Nutzt eine andere App dieselbe Datenbank, denselben Speicher oder dieselben Schlüssel wie diese? Wenn ja, bestimmt die schwächste App, wie sicher alle sind.
Bei TeamOnly
Übernommen. Jede App bekommt bei der ersten Veröffentlichung ihre eigene Datenbank, ihren Dateispeicher und ihre Secrets, und ihr Sitzungscookie ist an ihre eigene Adresse gebunden. Apps kommen nicht an die Daten anderer Apps.
Wer was darf, auf dem Server geprüft
Was schiefgeht
Die KI blendet den Button „Freigeben“ für die meisten aus, lässt die Route zum Freigeben aber für jeden Angemeldeten offen. Oder der Server vertraut einer Rolle oder E-Mail, die der Browser schickt. Fehlerhafte Zugriffskontrolle steht in den OWASP Top 10 auf Platz eins. Ungeprüfte Eingaben sind ein naher Verwandter: ein negativer Betrag, eine SQL-Abfrage, die aus einem Textfeld gebaut wird.
Selbst prüfen
Melden Sie sich als normale Kollegin oder normaler Kollege an und versuchen Sie, was nur Führungskräfte tun dürfen. Fragen Sie Ihr KI-Tool: „Wer darf jede API-Route aufrufen, und wo auf dem Server wird das geprüft? Verwenden alle Datenbankabfragen Platzhalter?“
Bei TeamOnly
Teilweise übernommen. Ihre App bekommt die verifizierte Person (ctx.user) und die Rollen, die Sie im Dashboard vergeben (ctx.user.roles), und gefälschte Identitäts-Header werden entfernt. Die Anweisungen sagen Ihrem KI-Tool, Platzhalter in Abfragen zu verwenden und Eingaben auf dem Server zu prüfen. Die Rolle in jeder Route zu prüfen ist Sache des Codes Ihrer App. TeamOnly prüft ihn nicht.
Jedes Paket ist echt und nötig
Was schiefgeht
KI-Tools schlagen manchmal Pakete vor, die es nicht gibt. Angreifer veröffentlichen Pakete unter diesen Namen, wer eines installiert, führt also den Code eines Fremden in seiner App aus.
Selbst prüfen
Öffnen Sie package.json. Schlagen Sie jeden Namen, den Sie nicht kennen, auf npmjs.com nach: Ein echtes Paket hat eine Geschichte, ein verlinktes Quell-Repository und stetige Downloads. Führen Sie vor der Veröffentlichung npm audit aus und entfernen Sie Pakete, die die App nicht mehr nutzt.
Bei TeamOnly
Nicht übernommen. TeamOnly durchsucht keine Pakete. Eine App kommt nur an ihre eigenen Daten und Schlüssel, das begrenzt, was ein schlechtes Paket erreichen kann, aber innerhalb dieser App könnte es trotzdem alles lesen.
Eine Aufzeichnung, wer was geändert hat
Was schiefgeht
Etwas wird freigegeben, gelöscht oder geändert, und niemand kann sagen, wer es war. KI-gebaute Apps führen selten einen Verlauf, außer Sie verlangen einen.
Selbst prüfen
Bitten Sie Ihr KI-Tool, bei jedem Datensatz festzuhalten, wer ihn angelegt und zuletzt geändert hat und wann, und eine Verlaufstabelle für Freigaben und Löschungen zu führen. Probieren Sie es aus: Ändern Sie einen Datensatz und suchen Sie dann Ihren Namen darauf.
Bei TeamOnly
Teilweise übernommen. Das Dashboard zeigt jede Veröffentlichung jeder App, mit wer und wann, und Live-Logs. Logs sind live, nicht gespeichert. Audit-Logs von Anmeldungen und Zugriffsänderungen gibt es im Business-Tarif, eingerichtet mit Ihnen. Der Verlauf in der App (wer eine Spesenabrechnung freigegeben hat) ist Aufgabe Ihrer App.
Eine verantwortliche Person, eine Sicherung und ein Plan für Ausscheidende
Was schiefgeht
Die Person, die gebaut hat, geht, und die App läuft weiter auf ihrem privaten Konto oder hört auf, wenn ihre Karte gekündigt wird. Oder eine schlechte Änderung löscht eine Tabelle, und es gibt keine Kopie.
Selbst prüfen
Schreiben Sie auf, wer für die App verantwortlich ist und wer übernimmt. Halten Sie den Code in einem Git-Repository der Firma. Bitten Sie Ihr KI-Tool, einen CSV-Export der wichtigsten Tabellen einzubauen, und probieren Sie ihn aus.
Bei TeamOnly
Teilweise übernommen. Apps gehören Ihrer Firma, und Admins können eine App an eine neue verantwortliche Person übergeben. Wird das Firmenkonto einer Person abgeschaltet, sind keine neuen Anmeldungen mehr möglich. Wer schon angemeldet ist, bleibt drin, bis die Sitzung endet, und Admins legen fest, wie lange das ist, von 8 Stunden bis 30 Tagen. Einen Button für Sicherung oder Export gibt es im Dashboard heute nicht, bauen Sie den Export also in die App ein.
03Zum Ausdrucken
Die Prüfung in einer Minute
Elf Fragen mit Ja oder Nein. Jedes „Nein“ ist das Nächste, was Sie beheben.
Bevor ich diese App teile
Ein privates Browserfenster zeigt eine Firmenanmeldung und sonst nichts.
Ein privates Gmail- oder Outlook-Konto wird abgewiesen.
Nur die Personen, die diese Daten brauchen, können sie öffnen.
Eine site:-Suche nach der Adresse der App findet nichts.
Kein Schlüssel, Token oder Passwort steht im Browsercode oder im Repository.
Die Datenbank ist nur über die App erreichbar.
Daten und Schlüssel dieser App teilt sie mit keiner anderen App.
Eine normale Kollegin oder ein normaler Kollege kann nicht tun, was nur Führungskräfte dürfen.
Jedes Paket in package.json ist echt und wird noch genutzt.
Datensätze zeigen, wer sie angelegt und geändert hat.
Jemand anderes weiß, dass er für diese App verantwortlich ist, wenn ich gehe, und die Daten lassen sich exportieren.
Fünfzehn Minuten mit der Person, die sie gebaut hat, bei geteiltem Bildschirm. Sie prüfen die Einrichtung, Sie lesen nicht jede Codezeile.
Wo sie läuft und wer sie erreicht
Lassen Sie sich die Adresse geben. Öffnen Sie sie von einem Gerät, das nicht angemeldet ist, und mit einem privaten Konto. Fragen Sie, welche Plattform sie hostet und wessen Konto dafür zahlt. Ein privates Konto ist das Erste, was sich ändern muss.
Welche Daten sie enthält
Fragen Sie, was hineinkommt und woher es stammt. Personenbezogene Kundendaten, Zahlungsdaten, Gesundheitsdaten oder Passwörter für andere Systeme legen die Messlatte höher und können bedeuten, dass die App auf eine Namensliste beschränkt werden sollte.
Wo die Schlüssel liegen
Listen Sie jeden externen Dienst auf, den die App aufruft. Jeder Schlüssel sollte in den Secret-Einstellungen des Hosters liegen, auf das beschränkt, was die App braucht, und nicht mit anderen Apps geteilt. Tauschen Sie jeden Schlüssel aus, der je im Code oder in einem Chat stand.
Wer was darf
Lassen Sie die Person, die gebaut hat, sich als normaler Nutzer anmelden, oder bitten Sie eine Kollegin oder einen Kollegen darum, und probieren Sie die Admin-Aktionen aus. Bitten Sie die Person, ihr KI-Tool jede API-Route auflisten zu lassen und wo sie die Rolle prüft. Lücken hier werden im Code der App behoben.
Pakete und Code
Sehen Sie sich package.json gemeinsam an und führen Sie npm audit aus. Bitten Sie darum, dass der Code in einem Git-Repository der Firma liegt, nicht nur auf dem Laptop der Person, die gebaut hat.
Die verantwortliche Person und der Tag, an dem sie geht
Tragen Sie die App, die verantwortliche Person, eine Vertretung, ihre Daten und ihre Nutzer in Ihre App-Liste ein. Vereinbaren Sie, was passiert, wenn die verantwortliche Person geht. Der Ratgeber zu Shadow-AI-Apps hat eine einseitige Richtlinie zum Übernehmen.
Kann ich Vibe-Coding-Apps bedenkenlos mit Kollegen teilen?
Das geht. Die üblichen Probleme liegen darin, wo die App läuft und wie sie eingerichtet wurde: ein öffentlicher Link, kein echter Login, Schlüssel im Browser, abgeschaltete Datenbankregeln. Jedes davon lässt sich in ein paar Minuten prüfen. Gehen Sie die Checkliste auf dieser Seite durch, bevor Sie den Link verschicken.
Was ist das größte Sicherheitsrisiko bei einer Vibe-Coding-App?
Daten, an die jeder ohne Anmeldung kommt. Das passiert meist auf eine von zwei Arten: Die App liegt unter einem öffentlichen Link ohne Login davor, oder die Datenbank beantwortet Anfragen direkt und ihre Zugriffsregeln sind aus (Row Level Security in Supabase). Beides ist eine Frage der Einrichtung, nicht davon, dass die KI schlechten Code schreibt.
Darf mein Supabase anon key im Browser stehen?
Der anon oder publishable key ist dafür gemacht, im Browser zu stehen, aber nur, weil Row Level Security begrenzt, worauf er zugreifen kann. Ist Row Level Security bei einer Tabelle aus, kann jeder mit diesem Schlüssel sie lesen und ändern. Der secret oder service_role key darf nie im Browser stehen: Er umgeht jede Regel.
Beschränkt „Mit Google anmelden“ eine App auf meine Firma?
Nicht von allein. Standardmäßig kann sich jedes Google-Konto anmelden, auch ein privates Gmail. Die Google-Einstellung hd grenzt nur die Kontoauswahl ein, und Google sagt, man solle sich nicht darauf verlassen. Der Server der App muss bei jeder Anfrage die Domain im verifizierten Anmelde-Token prüfen.
Wie prüfe ich, ob meine App bei Google indexiert ist?
Suchen Sie bei Google nach site: gefolgt von der Adresse Ihrer App, zum Beispiel site:myapp.lovable.app. Erscheinen Seiten, ist die App öffentlich und indexiert. Machen Sie die App privat oder ziehen Sie sie hinter einen Firmen-Login, und bitten Sie Google dann mit dem Tool „Entfernen“ in der Search Console, die Seiten zu entfernen, wenn Ihnen die Domain gehört.
Soll ich mein KI-Tool anweisen, sicheren Code zu schreiben?
Ja, und dauerhafte Anweisungen sind besser als einmal fragen. Eine Regeldatei im Projekt (CLAUDE.md, AGENTS.md oder eine Cursor-Regel) sagt dem Tool, wohin Schlüssel gehören, wie Datenbankabfragen geschrieben werden und wo Rollen geprüft werden. npx teamonly init fügt diese für TeamOnly Apps hinzu. Machen Sie die Prüfungen trotzdem selbst: Anweisungen verringern Fehler, sie beseitigen sie nicht.
Durchsucht TeamOnly den Code meiner App nach Sicherheitsproblemen?
Nein. TeamOnly stellt einen Firmen-Login vor jede App, hält Daten und Schlüssel jeder App getrennt und hält Apps aus Suchmaschinen heraus. Es prüft weder Ihren Code noch Ihre Pakete noch die Regeln in Ihrer App. Diese Punkte der Checkliste bleiben bei Ihnen.
Was sollte die IT prüfen, bevor sie eine KI-gebaute App freigibt?
Wo sie gehostet ist und wer sie erreicht, wie die Anmeldung beschränkt ist, wo die Schlüssel liegen, welche Daten sie enthält, wem sie gehört und was passiert, wenn diese Person geht. Der Abschnitt „Für die IT“ auf dieser Seite ist eine kurze Prüfung, die Sie in 15 Minuten mit der Person durchgehen, die die App gebaut hat.
Lassen Sie die Plattform die offenen Türen schließen.
Mit einem Befehl veröffentlichen, und die App liegt hinter Ihrem Firmen-Login, raus aus der Suche, mit eigener Datenbank und eigenen Secrets. 14 Tage kostenlos testen, ohne Karte.