Die 10 häufigsten Sicherheitslücken in KI-generiertem Code

Wie verbreitet das Problem ist, zeigt eine grosse Untersuchung von Veracode: Über 100 Sprachmodelle mussten 80 Programmieraufgaben lösen. In rund 45 % der Fälle enthielt der erzeugte Code eine Sicherheitslücke aus den OWASP Top 10. Bei Java lag die Quote über 70 %, und gegen Cross-Site-Scripting war der Code in 86 % der Fälle nicht abgesichert (Veracode, Juli 2025).

Das deckt sich mit dem, was wir in Projekten sehen. Die gute Nachricht: Die meisten Lücken folgen wenigen, wiederkehrenden Mustern.

1. Fehlende oder zu offene Zugriffsregeln

Die häufigste und gefährlichste Lücke. Die App prüft, ob jemand angemeldet ist – aber nicht, ob die angefragten Daten ihm gehören. Wer in der Adresse /rechnung/123 durch /rechnung/124 ersetzt, sieht die Rechnung eines anderen Kunden.

Bei Apps auf Supabase (typisch für Lovable und Bolt) heisst das konkret: Row-Level Security ist auf einzelnen Tabellen nicht aktiv oder die Regeln erlauben zu viel. Dann kann jeder, der den öffentlichen Schlüssel aus dem Browser kennt, die Daten direkt abfragen. Genau das war die Ursache von CVE-2025-48757 bei Lovable-Projekten.

So erkennen Sie es: Mit zwei Testkonten gegenseitig auf Daten zugreifen. Für Supabase haben wir eine Schritt-für-Schritt-Anleitung.

2. Geheime Schlüssel im Frontend oder im Repository

API-Schlüssel für OpenAI, Stripe oder den Supabase-Service-Zugang stehen direkt im Code, der an den Browser ausgeliefert wird – oder in einer .env-Datei, die mit ins Git-Repository gewandert ist. Alles, was im Browser landet, ist öffentlich. Ein Service-Schlüssel dort umgeht sämtliche Zugriffsregeln.

So erkennen Sie es: In den Entwicklertools des Browsers unter «Quellen» nach sk_, service_role oder secret suchen. Und im Repository die Historie prüfen – ein einmal eingecheckter Schlüssel ist auch nach dem Löschen noch da und muss ersetzt werden.

3. Prüfungen nur im Browser

Die KI baut ein Formular, das ungültige Eingaben ablehnt, und einen «Admin»-Knopf, der nur für Admins sichtbar ist. Die Server-Seite prüft beides nicht. Wer die Anfrage direkt schickt, umgeht jede Regel.

Faustregel: Jede Prüfung, die zählt – Berechtigung, Preis, Menge, Status –, gehört auf den Server. Im Browser ist sie nur Komfort.

4. Injection: SQL, Befehle und Prompts

Klassische SQL-Injection ist seltener geworden, weil moderne Bibliotheken parametrisierte Abfragen fördern. Wir finden sie trotzdem, sobald die KI für eine Suche oder einen Filter Abfragen aus Text zusammensetzt. Neu dazugekommen ist Prompt-Injection: Wenn Nutzereingaben ungefiltert in einen KI-Aufruf fliessen, der Werkzeuge oder Daten nutzen darf, kann ein Angreifer die KI umsteuern.

5. Cross-Site-Scripting (XSS)

Nutzerinhalte werden ungeprüft als HTML dargestellt – etwa mit dangerouslySetInnerHTML in React oder v-html in Vue, gern für «schön formatierte» Texte oder Markdown. Damit kann eingeschleuster Code im Browser anderer Nutzer laufen und deren Sitzung übernehmen.

6. Selbstgebaute Anmeldung

Statt eines bewährten Dienstes oder einer etablierten Bibliothek baut die KI ein eigenes Login: Passwörter mit einfachem Hash oder gar im Klartext, Sitzungs-Tokens im localStorage, kein Ablauf, kein Schutz vor Durchprobieren. Jeder einzelne Punkt ist lösbar – zusammen sind sie ein offenes Tor.

7. Veraltete und erfundene Pakete

KI-Modelle kennen den Stand ihrer Trainingsdaten. Sie schlagen Bibliotheksversionen mit bekannten Lücken vor – und gelegentlich Pakete, die es gar nicht gibt. Angreifer registrieren solche erfundenen Namen gezielt mit Schadcode.

So erkennen Sie es: npm audit, pnpm audit oder pip-audit laufen lassen und jedes unbekannte Paket vor der Installation auf der Registry nachschlagen.

8. Keine Limits – weder für Angreifer noch für Kosten

Ohne Rate-Limits lässt sich ein Login beliebig oft durchprobieren und ein Formular als Spam-Schleuder missbrauchen. Bei KI-Funktionen kommt ein zweites Risiko dazu: Jede Anfrage kostet Geld. Ein Bot, der Ihre Chat-Funktion tausendfach aufruft, steht danach auf Ihrer Rechnung beim KI-Anbieter.

9. Zu viel Offenheit im Betrieb

Ausführliche Fehlermeldungen mit Stacktraces in Produktion, CORS: * für alle Herkünfte, offene Admin- oder Debug-Endpunkte, Standard-Zugangsdaten als «Fallback» im Code. Jeder Punkt allein wirkt harmlos, zusammen liefern sie Angreifern die Landkarte.

10. Kein Logging, kein Monitoring, kein getestetes Backup

Keine Lücke im engeren Sinn – aber der Grund, warum aus einer Lücke ein Schaden wird. Ohne Protokolle merkt niemand einen Angriff. Ohne Alarmierung bemerkt ein Kunde den Ausfall zuerst. Und ohne ausprobiertes Backup ist der Datenverlust endgültig.

Was jetzt?

Drei Schritte bringen den grössten Gewinn pro Stunde Aufwand:

1. Zugriffsregeln prüfen (Punkt 1) – mit zwei Testkonten, eine halbe Stunde.
2. Nach Schlüsseln suchen (Punkt 2) – im Browser und in der Git-Historie, alles Gefundene sofort ersetzen.
3. Abhängigkeiten prüfen (Punkt 7) – ein Befehl, fünf Minuten.

Alles Weitere braucht einen Blick in den Code. Und dort zeigt sich oft, dass die Sicherheitslücken nur das sichtbare Symptom sind – die Ursache liegt meist in der Architektur.