Der Reiz der sofortigen App-Erstellung kollidiert mit grundlegender Sicherheit
KI-gestützte App-Builder haben es nahezu jedem ermöglicht, in Minuten eine Web-App zu erstellen und bereitzustellen. Diese Geschwindigkeit ist Teil ihres Reizes. Sie ist aber zunehmend auch Teil des Problems.
Laut einem Bericht von Wired auf Basis einer Untersuchung des Cybersicherheitsunternehmens RedAccess wiesen Tausende öffentlich zugängliche Apps, die mit Tools wie Lovable, Replit, Base44 und Netlify erstellt wurden, kaum oder gar keine nennenswerte Sicherheit auf. In mehr als 5.000 Fällen waren die Anwendungen für jeden zugänglich, der die URL kannte oder erriet. Rund 40 Prozent der untersuchten Apps legten sensible Informationen offen, sagte RedAccess-Mitgründer Dor Zvi.
Das im Bericht beschriebene Material ist nicht trivial. Zvi sagte, die Daten umfassten medizinische Informationen, Finanzdaten, Unternehmenspräsentationen, Strategiedokumente und Protokolle von Kunden-Chatbots. Wired sagte außerdem, mehrere der in Screenshots gezeigten offengelegten Anwendungen seien weiterhin online und zugänglich gewesen.
Es geht nicht nur um Bugs
Der wichtigste Punkt des Berichts ist, dass viele dieser Ausfälle keine subtilen Codefehler waren. Es handelte sich um fehlende oder fast nicht vorhandene Zugriffskontrollen. Einige Apps sollen jedem mit einem Browser Zugang zu den Daten gewährt haben. Andere verließen sich offenbar auf schwache Hürden, etwa darauf, dass Besucher sich mit jeder beliebigen E-Mail-Adresse anmelden konnten.
Diese Unterscheidung ist wichtig, weil sie das Bedrohungsmodell verändert. Sicherheitsteams sind es gewohnt, nach ausnutzbaren Schwachstellen in Software zu suchen. Was RedAccess beschreibt, ist grundlegender: Anwendungen gehen live, ohne überhaupt ein echtes Konzept dafür zu haben, wer hineingelassen werden sollte.
In diesem Sinne liegt das Risiko von „vibe-coded“ Apps nicht nur darin, dass KI neue Bugs einführt. Es liegt auch darin, dass dieselben Werkzeuge die Hürde für die Veröffentlichung von Software so stark senken, dass manche Ersteller grundlegende Sicherheitsentscheidungen komplett überspringen.
Wie die Apps gefunden wurden
RedAccess sagte, der Suchprozess sei überraschend einfach gewesen. Die im Bericht genannten Plattformen ermöglichen es, Apps auf den eigenen Domains der Unternehmen zu hosten statt auf vom Nutzer kontrollierten Domains. Die Forscher nutzten dann einfache Google- und Bing-Suchen auf diese Domains sowie weitere Suchbegriffe, um eine große Zahl von KI-erstellten Apps zu identifizieren.
Dieses Detail sollte sowohl Plattformanbieter als auch Organisationen beunruhigen, die solche Werkzeuge intern einsetzen. Es legt nahe, dass die offengelegten Apps nicht in obskuren Ecken des Webs verborgen waren. Sie waren mit gewöhnlichen Suchmethoden auffindbar. Sobald sie auffindbar sind, wird jede fehlende oder schwache Authentifizierung zu einem direkten Weg für Datenoffenlegung.
Warum das ein größeres Organisationsproblem sein könnte
Zvi beschrieb das Leckmuster in ungewöhnlich deutlichen Worten und sagte, Organisationen legten private Daten über Vibe-Coding-Anwendungen offen und nannte dies eines der größten Ereignisse überhaupt, bei dem sensible Informationen für jeden auf der Welt zugänglich gemacht wurden. Selbst wenn man die bei Sicherheitsenthüllungen übliche Rhetorik mit einrechnet, ist das zugrunde liegende Muster bedeutsam.
Die Verbreitung von KI-Entwicklungstools in Unternehmen bedeutet, dass Softwareerstellung nicht mehr auf klassische Engineering-Teams beschränkt ist. Produktmanager, Analysten, Marketer und Operations-Mitarbeiter können heute interne Tools oder kundenorientierte Prototypen mit einem Prompt und einem Deploy-Button zusammenbauen. Das verändert, wer Software schreibt, aber nicht, was Software offenlegen kann.
Wenn ein Mitarbeiter eine KI-erstellte App mit internen Daten verknüpft und mit den Standard-Einstellungen veröffentlicht, kann das zu einem vollständigen Leck führen, ohne dass ein böswilliger Angreifer überhaupt eine Perimeter-Verteidigung durchbrechen muss. Die Anwendung selbst wird zur Sicherheitslücke.
Der kulturelle Wandel hinter dem Problem
Ein Teil der Geschichte ist technisch, ein Teil kulturell. KI-Coding-Plattformen werden mit Unmittelbarkeit verkauft. Sie versprechen, dass Software so erstellt werden kann wie Präsentationen oder Dokumente: schnell, iterativ und ohne viel Spezialtraining. Dieses Versprechen ist stark, besonders in Organisationen, die schneller experimentieren wollen.
Aber Software ist nicht nur ein kreatives Artefakt. Sie ist auch eine Zugriffsschnittstelle. Je einfacher es wird, Apps zu erstellen, desto einfacher wird es, unsichere Apps in großem Maßstab zu erzeugen. In diesem Sinne liest sich der Wired-Bericht weniger wie ein isoliertes Anbieterproblem und mehr wie eine frühe Warnung vor einer neuen Art von Schatten-IT.
Das Problem verschärft sich, wenn Hosting, Bereitstellung und Auffindbarkeit in denselben Workflow eingebaut sind. Wenn ein Nutzer in Minuten eine App erzeugen, Daten anbinden und sie auf einer großen Plattformdomain veröffentlichen kann, muss Governance weiter nach vorne rücken. Sicherheit nach der Bereitstellung ist dann möglicherweise zu spät.
Was als Nächstes geschehen sollte
Der Bericht liefert keine formellen Antworten aller genannten Plattformen, daher ist die belastbarste Schlussfolgerung breiter als jedes einzelne Unternehmen. KI-App-Builder-Ökosysteme brauchen strengere Standardwerte für Authentifizierung und Datenoffenlegung. Nutzer brauchen klarere Warnungen darüber, was öffentlich wird. Und Organisationen müssen promptbasierte App-Builder als echte Softwareentwicklungsumgebungen behandeln, nicht als harmlose Produktivitätstools.
Die größere Lehre ist klar. Wenn die Erstellung von Apps sofort geschieht, kann Sicherheit nicht länger optional oder vorausgesetzt sein. Der eigentliche Durchbruch bei KI-Softwaretools wird nicht nur daran gemessen, wie schnell sie Code veröffentlichen können. Er wird daran gemessen, ob sie unerfahrene Ersteller davon abhalten können, ihre Daten gleich mit zu veröffentlichen.
Dieser Artikel basiert auf einem Bericht von Wired. Den Originalartikel lesen.
Originally published on wired.com




