Apps mit Lovable, Cursor & Co entwickeln: Droht ein Sicherheitsrisiko?
Risiken, Mythen und Compliance erklärt
Die Versuchung ist groß, eine App nicht mehr zu bezahlen, sondern stattdessen einfach selbst zu prompten. Ein paar Sätze und ein paar Klicks später steht ein funktionierendes Frontend, die API antwortet und das Deployment wirkt so beiläufig wie ein Kaffeeholen.
05.02.2026
Wie gut ist Software, die eher beschrieben als gebaut wurde?
Diese Leichtigkeit fühlt sich modern an und passt perfekt zur aktuellen Entwicklungskultur, die allerdings auch ihre Grenzen hat. Deutlich wird diese Grenze bei hochkomplexen Systemen, beispielsweise Slots wie Lucky Pharaoh Wild, wo es auf Auszahlungsmodellen oder regulatorisch relevante Glücksspielsysteme ankommt. Solche Konstrukte basieren auf Wahrscheinlichkeitsrechnung, Zustandsmaschinen und strengen Vorgaben und lassen sich nicht einfach aus ein paar Prompts zusammensetzen.
Gleichzeitig wächst generell ein leises Unbehagen, weil dieselbe Bequemlichkeit in der Programmierung eine Frage aufdrängt, die sich nicht wegprompten lässt: Wie belastbar ist Software, die eher beschrieben als gebaut wurde?
KI-gestützte App-Entwicklung und ihre Grenzen
KI-gestützte Entwicklungswerkzeuge nehmen Arbeit ab, indem sie Code generieren, Dateien strukturieren und ganze Abläufe zusammenstecken, ohne dass jede Zeile von Hand geschrieben wird. Für Prototypen, interne Tools oder erste Ideenskizzen funktioniert das erstaunlich gut, weil typische Muster erkannt und reproduziert werden. Im Frontend-Bereich entsteht so in kurzer Zeit etwas, das visuell und funktional überzeugt und schnelle Entscheidungen ermöglicht. Problematisch wird es dort, wo aus einem funktionierenden Entwurf eine Anwendung entstehen soll, die langfristig betrieben wird und reale Nutzer sowie echte Daten verarbeitet. Spätestens an diesem Punkt zeigt sich, dass Tempo allein kein Qualitätsmerkmal ist.
Sicherheit ist kein sichtbares Feature, das sich aus Beispielen zusammensetzt, sondern das Ergebnis aus Architektur, Validierung und einem gesunden Misstrauen gegenüber allen Eingaben. An dieser Stelle stoßen solche Systeme an ihre Grenzen, weil Zusammenhänge eher nachgeahmt als verstanden werden. Eine KI erkennt, wie Login-Code aussieht, nicht jedoch, weshalb bestimmte Schutzmechanismen notwendig sind oder an welcher Stelle sie zwingend greifen müssen.
Eine KI versteht nicht, warum eine Authentifizierung robust ist oder weshalb bestimmte Daten niemals im Frontend auftauchen sollten. Sie reproduziert Code, der oft sauber aussieht und zuverlässig läuft, dabei jedoch grundlegende Sicherheitsannahmen ignoriert. Missbrauchspotenzial und reale Angriffsflächen durch KI-Tools
Plattformen, die komplette Web-Apps inklusive Hosting per Texteingabe erzeugen, zeigen deutlich, wie schmal der Grat aus Effizienz und Missbrauch ist. Dieselbe Infrastruktur, die Entwicklern Zeit spart, eignet sich hervorragend für Phishing-Seiten, Fake-Shops oder täuschend echte Zahlungsportale. Der technische Aufwand ist gering, das Ergebnis wirkt professionell und diese Kombination ist gefährlich. Angriffe lassen sich skalieren, ohne tiefes technisches Wissen vorauszusetzen. Dadurch entsteht eine neue Qualität von Massenbetrug, die klassische Filtermechanismen zunehmend umgeht.
Die Einstiegshürde ist minimal und das macht solche Dienste für Cyberkriminelle attraktiv, weil Inhalte schnell angepasst und in großer Zahl ausgerollt werden können. Domains wirken generisch, Layouts vertrauenswürdig und der Quellcode ist häufig kaum von legitimen Projekten zu unterscheiden. Nutzer sehen eine saubere Oberfläche und hinterfragen selten, wie sie entstanden ist oder wer dahintersteht. Das Risiko verschiebt sich damit vom Angreifer zum Opfer, während die technische Herkunft der Seite in den Hintergrund tritt. Gleichzeitig wird die Aufdeckung solcher Seiten deutlich erschwert, da sie nicht mehr amateurhaft wirken.
Technische Schwachstellen in KI-Editoren wie Cursor und ähnlichen Systemen
KI-Editoren versprechen Unterstützung dort, wo klassische Entwicklungen aufhören, öffnen jedoch zusätzliche Angriffsflächen. Dokumentierte Schwachstellen reichen von Prompt-Injection bis hin zur ungewollten Ausführung von Befehlen. Kritisch sind Funktionen, bei denen Code automatisch ausgeführt oder externe Dateien ungeprüft eingebunden werden. Solche Komfortfunktionen sparen Zeit, setzen jedoch ein hohes Maß an Vertrauen voraus. Dieses Vertrauen ist technisch kaum abgesichert und wird häufig stillschweigend vorausgesetzt.
Dieses Vertrauen ist problematisch, weil Kontexte leicht manipulierbar sind. Ein scheinbar harmloser Kommentar oder eine versteckte Konfigurationsdatei kann ausreichen, um das Verhalten der KI zu beeinflussen. Der Editor reagiert dann nicht auf den sichtbaren Code, sondern auf implizite Anweisungen aus dem Projektumfeld. Dadurch entstehen Angriffsvektoren, die in klassischen Entwicklungsumgebungen kaum eine Rolle spielen. Entwickler verlieren auf diese Weise ein Stück Kontrolle über das tatsächliche Geschehen im Projekt.
Solche Mechanismen lassen sich ausnutzen, indem Kontexte vergiftet oder scheinbar harmlose Dateien eingeschleust werden. Die KI folgt dann Anweisungen, die nicht aus dem sichtbaren Code stammen, sondern aus versteckten Informationen im Projekt. Das Ergebnis können veränderte Konfigurationen, ausgeführte Fremdbefehle oder umgangene Berechtigungen sein. Diese Risiken unterscheiden sich von klassischen Bugs, weil sie aus der Wechselwirkung von Mensch, KI und Entwicklungswerkzeug entstehen und dadurch schwerer zu erkennen sind. Zusätzlich lassen sie sich oft nur schwer reproduzieren und gezielt beheben.
Vibe Coding begünstigt oft unsicheren Code
Vibe Coding beschreibt weniger eine Technik als eine Haltung, denn es geht darum, schnell etwas Lauffähiges zu erzeugen und sich vom Flow tragen zu lassen. Dieses Vorgehen fühlt sich produktiv an und belohnt sofort mit sichtbaren Ergebnissen. Gleichzeitig verführt es dazu, unbequeme Fragen aufzuschieben, weil sie den kreativen Prozess bremsen. An diesem Punkt beginnt das Sicherheitsproblem, das sich erst deutlich später bemerkbar macht.
Diese Herangehensweise kann kreativ sein, fördert jedoch Nachlässigkeit an Stellen, die keine sichtbaren Effekte haben. Eingaben werden nicht sauber validiert, Datenbankabfragen bleiben offen und Fehlerbehandlung wird auf später verschoben. Solange alles funktioniert, scheint das kein Problem zu sein und erzeugt ein trügerisches Gefühl von Stabilität. Erst unter Last oder bei gezielten Angriffen zeigen sich die Schwächen. Dann fehlt häufig die Zeit, grundlegende Entscheidungen nachzuholen.
KI-Tools verantwortungsvoll einsetzen
Trotz aller Kritik sind KI-gestützte Entwicklungswerkzeuge kein Sicherheitsproblem an sich. Riskant werden sie erst dann, wenn sie als Ersatz für grundlegende Entwicklungsprinzipien verstanden werden. Richtig eingesetzt können sie Abläufe beschleunigen und monotone Aufgaben abnehmen, ohne die Qualität zwangsläufig zu senken. Die entscheidende Frage lautet, ob die Kontrolle beim Menschen bleibt. Dort liegt letztlich die Verantwortung.
Manuelle Code-Reviews bleiben unverzichtbar, ebenso automatisierte Sicherheitsprüfungen, die typische Schwachstellen erkennen. Sie sorgen dafür, dass generierter Code nicht ungeprüft in produktive Systeme gelangt. Isolierte Testumgebungen helfen dabei, neue Ideen auszuprobieren, ohne reale Daten zu gefährden. Gerade in frühen Entwicklungsphasen ist diese Trennung essenziell und verhindert spätere Altlasten.
Entscheidend ist der Umgang mit sensiblen Informationen. Zugangsdaten und Secrets gehören weder in Prompts noch in generierten Frontend-Code. Für produktive Anwendungen empfiehlt sich eine klare Trennung aus sicherem Backend, kontrollierten Schnittstellen und nachvollziehbaren Deployments. KI kann dabei unterstützen, sie sollte jedoch nie die letzte Instanz sein. Wer diese Werkzeuge als Beschleuniger versteht und nicht als Abkürzung nutzt, kann ihre Stärken einsetzen, ohne ihre Schwächen zu ignorieren.
