Sicherheits-Checkliste für mit KI gebaute Apps: was du vor dem Start prüfen solltest

Bevor echte Menschen eine App nutzen, die du mit KI gebaut hast, prüfe sieben Dinge: Jede Seite und jede API prüft, wer der Nutzer ist und was er darf; geheime Schlüssel liegen auf dem Server, nie im Browser oder im Chat; alle Eingaben werden auf dem Server validiert; jeder Nutzer erreicht nur seine eigenen Datensätze; Login und kostenintensive Endpunkte sind rate-limitiert; Abhängigkeiten sind aktuell; und du kannst deine Daten wiederherstellen, falls etwas schiefgeht. Die Checkliste unten macht daraus konkrete Tests, die du ohne Code-Lesen durchführen kannst.

KI-App-Builder sind gut darin, Funktionen zum Laufen zu bringen. Sorgfalt kommt von allein nicht, weil sie selten im Prompt steht. Die meisten Probleme unten entstehen durch Dinge, nach denen niemand gefragt hat. Die Lösung ist deshalb meist, danach zu fragen.

So verwendest du diese Checkliste

Arbeite sie der Reihe nach ab und mache bei jedem Punkt zwei Dinge: frage die KI, ob er umgesetzt ist, und teste ihn selbst. Die KI kann eine Berechtigungsprüfung schreiben; nur ein Test zeigt dir, dass sie funktioniert. Die Punkte sind so markiert:

• Muss — vor der ersten Nutzung durch andere erledigen.
• Sollte — erledigen, bevor du echte Nutzer oder echte Daten hast.
• Später — lohnt sich, wenn die App wächst.

Wenn du nur eine Stunde hast, erledige alle Muss-Punkte.

1. Authentifizierung: Wer ist das?

Authentifizierung bedeutet, zu bestätigen, wer jemand ist, meist beim Login. Die Grundlagen findest du unter was Authentifizierung ist, die Optionen unter wie du Login zu deiner App hinzufügst.

• Muss: Jede Seite mit privaten Daten verlangt einen Login. Test: Melde dich ab und füge die URL einer privaten Seite direkt in den Browser ein.
• Muss: Jeder API-Endpunkt hinter diesen Seiten verlangt ebenfalls einen Login, nicht nur die Seite. Test: Melde dich ab, öffne im Browser den Netzwerk-Tab und wiederhole eine Anfrage, die die App gestellt hat, während du angemeldet warst.
• Muss: Passwörter werden mit einem langsamen Passwort-Hash-Verfahren gehasht gespeichert, niemals im Klartext. Die Passwort-Speicherungsrichtlinien der OWASP empfehlen zuerst Argon2id, mit scrypt, bcrypt oder PBKDF2 als Alternativen. Frage: „Wie werden Passwörter gespeichert?“
• Sollte: Links zum Zurücksetzen von Passwörtern laufen ab und funktionieren nur einmal.
• Sollte: Session-Cookies sind mit Secure, HttpOnly und SameSite markiert, und Abmelden beendet die Sitzung auch auf dem Server.
• Später: Biete Zwei-Faktor-Authentifizierung an oder Anmeldung über einen Anbieter, der sie unterstützt.

Prüfe jede API-Route und jede Seite, die Nutzerdaten zurückgibt. Jede davon muss Anfragen von nicht angemeldeten Nutzern ablehnen, und zwar auf dem Server, nicht nur im Code der Seite. Liste die geprüften Routen auf.

2. Autorisierung: Was darf diese Person tun?

Autorisierung ist der Schritt nach dem Login: Festlegen, was dieser konkrete Nutzer sehen und ändern darf. Hier haben mit KI gebaute Apps am häufigsten ernsthafte Lücken, denn die App wirkt richtig, weil das Dashboard jedes Nutzers nur seine eigenen Daten zeigt, während der Server die Daten jedes Nutzers herausgibt, sobald man sie direkt anfragt.

• Muss: Jedes Lesen, Ändern und Löschen prüft auf dem Server, dass der Datensatz dem aktuellen Nutzer (oder seinem Team) gehört.
• Muss: Teste es: Lege zwei Konten an, A und B. Öffne als A einen Datensatz von A und notiere die ID in der URL oder der Netzwerkanfrage. Melde dich als B an und rufe dieselbe ID auf. B muss einen Fehler erhalten, nicht die Daten von A.
• Muss: Admin-Seiten und Admin-API-Endpunkte prüfen die Rolle des Nutzers auf dem Server. Einen Admin-Link zu verstecken ist kein Schutz.
• Muss: Nutzer können ihre eigene Rolle, ihren Preis, ihr Guthaben oder Besitzerfelder nicht durch Bearbeiten der Anfrage ändern. Test: Schau im Netzwerk-Tab nach, was eine Profilaktualisierung sendet. Wenn sie Felder wie role oder isAdmin enthält, bitte die KI, diese vom Client aus zu ignorieren.
• Sollte: IDs in URLs sind schwer zu erraten (zufällige IDs statt 1, 2, 3). Das ersetzt keine Berechtigungsprüfung, begrenzt aber den Schaden, wenn eine fehlt.

Prüfe für jeden Endpunkt, der einen Datensatz liest oder ändert, auf dem Server, dass der angemeldete Nutzer ihn besitzt oder darauf zugreifen darf. Gib sonst 404 zurück. Zeige mir dann, wie du das mit zwei Konten testen würdest.

3. Zeilenbasierte Zugriffe in der Datenbank

„Zeilenbasierter Zugriff“ bedeutet, dass jede Zeile einer Tabelle (eine Buchung, eine Rechnung) nur für die Nutzer sichtbar ist, denen sie gehört. Dafür gibt es zwei gängige Wege:

Beide lassen sich gut umsetzen. Wichtig ist:

• Muss: Wenn der Browser direkt mit der Datenbank spricht (manche gehosteten Datenbankprodukte erlauben das), sind zeilenbasierte Regeln für jede Tabelle aktiviert. Ohne sie kann jeder mit dem öffentlichen Schlüssel die ganze Tabelle lesen.
• Muss: Abfragen filtern nach dem aktuellen Nutzer oder Team, nicht nach einer ID, die der Browser sendet.
• Sollte: Gemeinsame Daten (die Projekte eines Teams) haben eine klare Regel, wer im Team ist, und diese wird an einer einzigen Stelle durchgesetzt.

4. Geheimnisse und API-Schlüssel

Ein API-Schlüssel ist ein Passwort für einen Dienst. Stripe, E-Mail- und KI-Anbieter nutzen alle solche Schlüssel. Hintergrund dazu findest du unter was Umgebungsvariablen und Secrets sind.

• Muss: Schlüssel werden in den Umgebungsvariablen oder Secrets des Projekts gespeichert, niemals fest im Code.
• Muss: Schlüssel, mit denen Geld ausgegeben oder private Daten gelesen werden können, werden nur auf dem Server verwendet. Test: Öffne deine Live-Seite, zeige den Seitenquelltext und die JavaScript-Dateien in den Entwicklerwerkzeugen an und suche nach dem Anfang deines Schlüssels (zum Beispiel sk_). Er darf dort nicht vorkommen.
• Muss: Schlüssel wurden nie in den Chat, ein öffentliches Repository oder einen Screenshot eingefügt. Falls doch, rotiere ihn beim Anbieter (neuen erstellen, alten löschen).
• Sollte: Verwende eingeschränkte oder begrenzte Schlüssel, wo der Anbieter sie anbietet. Stripe empfiehlt zum Beispiel eingeschränkte Schlüssel, die nur die Berechtigungen haben, die deine Integration braucht.
• Sollte: Test- und Live-Schlüssel sind getrennt, und die Live-App verwendet Live-Schlüssel erst, wenn du bereit bist.

Manche Schlüssel sind dafür gedacht, öffentlich zu sein, etwa Stripes veröffentlichbarer Schlüssel (pk_…) oder ein Karten-Schlüssel, der auf deine Domain beschränkt ist. Die Regel betrifft Schlüssel, die Macht verleihen, nicht jede Zeichenfolge, die wie ein Schlüssel aussieht.

5. Eingabeprüfung

Alles, was ein Nutzer sendet — Formularfelder, Datei-Uploads, URL-Parameter — kann beliebig sein, nicht nur das, was dein Formular erlaubt.

• Muss: Die Validierung passiert auf dem Server, nicht nur im Browser. Browserprüfungen dienen der Bequemlichkeit; jeder kann sie umgehen.
• Muss: Datenbankabfragen verwenden Parameter, nicht aneinandergeklebten Text aus Nutzereingaben (das verhindert SQL-Injection). Lass dir von der KI bestätigen, dass das so ist.
• Muss: Text, den Nutzer eingeben, wird als Text angezeigt, nicht als HTML ausgeführt. Test: Gib <b>hallo</b> als deinen Namen ein. Du solltest die Tags sehen, nicht fettgedruckten Text.
• Sollte: Datei-Uploads prüfen Typ und Größe, und hochgeladene Dateien werden nicht von der Hauptdomain deiner App als ausführbare Seiten ausgeliefert.
• Sollte: Fehlermeldungen für Nutzer sind schlicht („Da ist etwas schiefgelaufen“); detaillierte Fehler landen nur in den Server-Logs.
• Sollte: Webhooks von Diensten wie Stripe prüfen die Signatur des Anbieters, bevor sie etwas auslösen. Siehe was ein Webhook ist.

Füge serverseitige Validierung zu jedem Formular und jedem API-Endpunkt hinzu: Pflichtfelder, Längen, Formate und erlaubte Werte. Alles andere wird mit einer klaren Meldung abgelehnt. Zeige Nutzern keine internen Fehlerdetails.

6. Rate-Limits und Missbrauch

Ein Rate-Limit begrenzt, wie viele Anfragen jemand in einem Zeitraum stellen kann. Ohne sie kann jeder den ganzen Tag Passwörter erraten, dein Anmeldeformular fluten oder eine kostenpflichtige API auf deine Rechnung laufen lassen.

• Muss: Login, Registrierung und Passwort-Zurücksetzen sind pro IP-Adresse und pro Konto rate-limitiert.
• Muss: Alles, was dich pro Aufruf Geld kostet — KI-Modellanfragen, SMS, E-Mails — hat ein Limit pro Nutzer und erfordert einen Login.
• Sollte: Öffentliche Formulare (Kontakt, Warteliste) haben einen Spam-Schutz: ein Rate-Limit, ein verstecktes Honeypot-Feld oder ein CAPTCHA.
• Sollte: Lege bei deinen kostenpflichtigen Anbietern Ausgabenlimits oder Warnungen fest, damit ein Fehler oder ein Angreifer keine unbegrenzte Rechnung erzeugen kann.

7. Abhängigkeiten

Apps bestehen aus Open-Source-Paketen, und Pakete haben manchmal bekannte Sicherheitslücken.

• Sollte: Lass die KI auf bekannte Schwachstellen prüfen (bei JavaScript-Projekten npm audit oder das Äquivalent deines Paketmanagers) und betroffene Pakete aktualisieren.
• Sollte: Entferne Pakete, die die App nicht mehr nutzt.
• Sollte: Sei vorsichtig bei Paketen mit sehr wenigen Nutzern oder Namen, die wie Tippfehler beliebter Pakete aussehen.
• Später: Prüfe alle ein bis zwei Monate erneut oder aktiviere automatische Warnungen, wenn dein Code auf GitHub liegt.

8. Backups und Wiederherstellung

Sicherheit umfasst auch die Fähigkeit, sich von Fehlern zu erholen — deinen eigenen, denen der KI oder denen eines Angreifers.

• Muss: Wisse, wo deine Daten liegen und ob sie gesichert werden. Nimm nichts an; prüfe die Dokumentation deines Hostings.
• Sollte: Behalte einen eigenen, regelmäßigen Export wichtiger Daten (zum Beispiel eine CSV-Exportfunktion oder einen Datenbank-Dump) an einem separaten Ort.
• Sollte: Bewahre deinen Code in einer Versionsverwaltung auf, damit jede Version wiederhergestellt werden kann.
• Sollte: Destruktive Aktionen (Konto löschen, Projekt löschen) verlangen eine Bestätigung; erwäge ein „Soft Delete“, das eine Zeit lang rückgängig gemacht werden kann.
• Später: Teste einmal tatsächlich eine Wiederherstellung. Ein Backup, das du nie wiederhergestellt hast, ist eine Hoffnung, kein Plan.

9. Vor dem Start

• Muss: Die Live-Seite nutzt überall HTTPS.
• Muss: Testdaten, Testkonten und Debug-Seiten aus der Entwicklung sind entfernt.
• Sollte: Eine Datenschutzerklärung sagt, welche Daten du erhebst und warum — in vielen Ländern Pflicht, wenn du personenbezogene Daten erhebst. Behaupte keine Zertifizierungen (SOC 2, HIPAA), die du nicht hast.
• Sollte: Es gibt einen Weg, dich zu Sicherheitsproblemen zu kontaktieren, und du weißt, wie du jeden Schlüssel schnell rotierst.

Für eine breitere Prüfung vor dem Start, über die Sicherheit hinaus, siehe wie du einen KI-Prototyp in die Produktion bringst.

Wann du eine professionelle Prüfung brauchst

Eine Checkliste fängt typische Fehler ab, sie ersetzt aber keinen Experten. Erwäge eine bezahlte Prüfung, wenn du Kartennummern selbst verarbeitest statt über einen gehosteten Checkout, Gesundheits-, Finanz- oder Kinderdaten speicherst, an Unternehmen verkaufst, die Sicherheitsfragebögen verlangen, oder bei einem Datenleck ernsthaft geschädigt würdest. Wenn sich dein Code exportieren lässt, wird eine solche Prüfung deutlich einfacher.

Sicherheit beim Bauen mit Mythex

Mythex hat kein Sicherheits-Scan-Panel, deshalb ist die Checkliste oben der Prozess, dem du folgen solltest. Einige Dinge helfen dabei:

• Projekt-Secrets. Lege Schlüssel unter Projekteinstellungen → Secrets an oder über die Secrets-Karte, die der Agent im Chat zeigt, damit sie aus deinem Code und deinen Nachrichten herausbleiben. Nach einer Änderung eines Secrets für eine Live-App veröffentliche erneut.
• Plan- und Ask-Modus. Bitte den Agenten, Berechtigungen zu prüfen, ohne etwas zu ändern: „Liste im Ask-Modus jede API-Route und die Berechtigungsprüfung auf, die sie durchführt.“
• /test lässt den Agenten deine Vorschau als Nutzer durchklicken — nützlich für den Test mit zwei Konten aus Abschnitt 2.
• Checkpoints erlauben dir, eine Änderung zurückzunehmen, die etwas kaputt gemacht hat.

Siehe Sicherheit für Apps, die du baust und Umgebungsvariablen und Secrets in der Dokumentation. Wenn du als Nächstes Nutzerkonten hinzufügst, lies wie du Login zu deiner App hinzufügst.

Fragen