Sicherheit für deinen AI-Prototyp: Was du schützen musst

Du hast einen Prototyp gebaut, 20 Leute haben sich registriert und es funktioniert. Aber hast du dich jemals gefragt: Kann jemand die Daten meiner Nutzer stehlen? Kann jemand sich als anderer Nutzer einloggen? Kann jemand meine Datenbank löschen?

Die ehrliche Antwort: Bei den meisten AI-gebauten Prototypen lautet die Antwort auf mindestens eine dieser Fragen: Ja.

Das ist kein Grund zur Panik. Aber es ist ein Grund, die grundlegenden Sicherheits-Basics zu kennen und umzusetzen — bevor ein Fremder es für dich herausfindet.

Warum AI-Prototypen oft unsicher sind

AI Tools wie Lovable und Bolt bauen funktionierenden Code. Aber „funktionierend” und „sicher” sind zwei verschiedene Dinge.

Was AI Tools gut machen: - Login-Formulare erstellen - Daten in einer Datenbank speichern - Seiten nur für eingeloggte Nutzer anzeigen

Was AI Tools oft vergessen: - Row Level Security (wer darf welche Daten sehen?) - Input-Validierung (was passiert bei böswilligen Eingaben?) - API-Absicherung (kann jemand die Datenbank direkt ansprechen?) - Passwort-Regeln (akzeptiert die App „123” als Passwort?) - Rate Limiting (kann jemand 10.000 Login-Versuche pro Minute starten?)

Das Problem: Die App funktioniert auch ohne diese Absicherungen. Du merkst erst dass sie fehlen, wenn es zu spät ist.

Die 7 Security-Basics für jeden Prototyp

1. Row Level Security (RLS) aktivieren

Was es ist: RLS bestimmt, dass Nutzer A nur die Daten von Nutzer A sehen kann — nicht die von Nutzer B, C oder D.

Warum es kritisch ist: Ohne RLS kann theoretisch jeder eingeloggte Nutzer die Daten aller anderen Nutzer lesen. Das ist ein massiver DSGVO-Verstoß und ein Vertrauensbruch.

Wie du es prüfst: In Supabase → Table Editor → Jede Tabelle: Steht dort „RLS enabled”?

Prompt-Fix: „Aktiviere Row Level Security für alle Tabellen. Erstelle Policies: Authentifizierte Nutzer können nur Zeilen lesen, erstellen, updaten und löschen wo user_id = auth.uid().”

2. API-Keys nicht im Frontend

Was es ist: Dein Supabase-Projekt hat zwei Keys: einen öffentlichen (anon key) und einen geheimen (service role key). Der geheime Key hat vollen Zugriff auf alles.

Warum es kritisch ist: Wenn der Service Role Key in deinem Frontend-Code steht, kann jeder der deine App öffnet den Key in den Browser-Tools finden — und hat dann vollen Zugriff auf deine gesamte Datenbank.

Wie du es prüfst: Suche in deinem Code nach „service_role” oder „SUPABASE_SERVICE_ROLE_KEY.” Wenn dieser Key irgendwo im Frontend auftaucht, ist das ein Problem.

Die Regel: Der anon key darf im Frontend sein (er ist dafür gedacht, in Kombination mit RLS). Der service role key gehört NIE ins Frontend. Er gehört in Umgebungsvariablen auf dem Server.

3. Passwort-Anforderungen setzen

Was es ist: Mindestanforderungen an Passwörter damit Nutzer nicht „123” oder „passwort” verwenden.

Warum es wichtig ist: Schwache Passwörter sind die einfachste Eintrittspforte. Ein Angreifer probiert die 100 häufigsten Passwörter und ist bei 10% der Accounts erfolgreich.

Wie du es umsetzt: - Supabase → Authentication → Settings → Password Requirements - Minimum 8 Zeichen - Mindestens ein Großbuchstabe und eine Zahl

Prompt-Fix: „Füge Passwort-Validierung hinzu: Minimum 8 Zeichen, mindestens ein Großbuchstabe und eine Zahl. Zeige dem Nutzer eine klare Fehlermeldung wenn das Passwort zu schwach ist.”

4. HTTPS sicherstellen

Was es ist: Die verschlüsselte Verbindung zwischen dem Browser deines Nutzers und deinem Server. Erkennbar am Schloss-Symbol in der Browserleiste.

Warum es kritisch ist: Ohne HTTPS können Dritte alles mitlesen was über die Verbindung läuft — Passwörter, E-Mails, persönliche Daten.

Die gute Nachricht: Vercel, Netlify und Lovable liefern HTTPS automatisch. Auch bei eigenen Domains. Wenn du deine App über diese Plattformen hostest, bist du abgesichert.

Wie du es prüfst: Öffne deine App im Browser. Steht „https://” am Anfang der URL und ist ein Schloss-Symbol sichtbar? Dann passt es.

5. Keine sensiblen Daten im Frontend anzeigen

Was es ist: Daten die nur auf dem Server existieren sollten, werden manchmal versehentlich ans Frontend geschickt.

Beispiele: - Die API gibt die E-Mails aller Nutzer zurück (obwohl nur der eigene Name angezeigt werden soll) - Die Profil-Seite enthält versteckte Felder mit der Datenbank-ID anderer Nutzer - Fehlermeldungen zeigen Datenbankstruktur oder interne Pfade

Wie du es prüfst: Öffne die Browser-Entwicklertools (F12) → Netzwerk-Tab. Klick durch deine App und schau welche Daten in den API-Antworten stehen. Wenn dort Daten auftauchen die du nicht auf dem Bildschirm zeigst — ist das verdächtig.

Prompt-Fix: „Stelle sicher dass die API nur die Felder zurückgibt die der Nutzer auf dem Bildschirm sehen soll. Keine überflüssigen Felder, keine IDs anderer Nutzer.”

6. Input-Validierung

Was es ist: Prüfen ob Nutzereingaben das sind was du erwartest — und nicht etwas Böswilliges.

Warum es wichtig ist: Ohne Validierung kann jemand statt eines Namens einen Code eingeben der deine Datenbank angreift (SQL Injection) oder schädliche Scripts einschleust (Cross-Site Scripting).

Die Basics: - E-Mail-Felder dürfen nur E-Mail-Adressen akzeptieren - Zahlen-Felder dürfen nur Zahlen akzeptieren - Text-Felder sollten HTML-Tags entfernen - Kein Feld sollte unbegrenzt lange Eingaben akzeptieren

Prompt-Fix: „Füge Input-Validierung für alle Formulare hinzu. E-Mail-Felder nur E-Mail-Format, Zahlenfelder nur Zahlen, Textfelder max. 1.000 Zeichen, HTML-Tags in Eingaben entfernen.”

7. Regelmäßige Backups

Was es ist: Eine Kopie deiner Daten, falls etwas schiefgeht.

Warum es wichtig ist: Ein versehentliches Löschen, ein Bug der Daten überschreibt, oder ein Angriff — ohne Backup sind die Daten weg.

Bei Supabase: - Free Plan: Keine automatischen Backups - Pro Plan (25 $/Monat): Tägliche automatische Backups - Manuell: Table Editor → Export als CSV (regelmäßig machen)

Empfehlung: Solange du auf dem Free Plan bist, exportiere einmal pro Woche die wichtigsten Tabellen als CSV. Wenn deine App geschäftskritisch wird, upgrade auf den Pro Plan.

Der Security-Quick-Check: 5 Minuten

Nimm dir 5 Minuten und prüfe diese 7 Punkte:

Wenn du 5 von 7 mit Ja beantworten kannst, bist du besser aufgestellt als 80% aller AI-gebauten Prototypen. Wenn nicht: Die Prompts oben helfen dir die wichtigsten Lücken sofort zu schließen.

Was AI Tools absichern — und was nicht

Die grün markierten Punkte passieren automatisch. Die roten musst du selbst prüfen und nachbessern. Für die letzten beiden (Rate Limiting und Monitoring) brauchst du in der Prototyp-Phase noch nichts tun — aber bei der Professionalisierung sind sie Pflicht.

Wann du professionelle Hilfe brauchst

Die 7 Basics kannst du selbst umsetzen. Aber es gibt einen Punkt ab dem du Hilfe brauchst:

Noch selbst machbar: - RLS aktivieren und grundlegende Policies setzen - Passwort-Anforderungen konfigurieren - API-Keys prüfen - Input-Validierung prompten

Profi-Terrain: - Penetration Testing (systematisch Schwachstellen finden) - OWASP Top 10 vollständig abdecken - Rate Limiting und DDoS-Schutz - Professionelles Logging und Monitoring - Audit Trail (wer hat wann was geändert) - Verschlüsselung sensibler Daten in der Datenbank

Ein erfahrener Entwickler deckt in der ersten Woche die OWASP Top 10 ab — die 10 häufigsten Sicherheitslücken in Web-Anwendungen. Das ist der Unterschied zwischen „es funktioniert” und „es ist sicher.”

FAQ: Häufig gestellte Fragen

Mein Prototyp hat nur 20 Nutzer. Muss ich mich um Sicherheit kümmern?

Ja — sobald du echte E-Mail-Adressen und Passwörter speicherst. Auch bei 20 Nutzern bist du für deren Daten verantwortlich. Die 7 Basics oben kosten dich 30 Minuten. Ein Datenleck kostet dich Vertrauen und möglicherweise Geld.

Kann mein AI-Prototyp gehackt werden?

Ja. Jede Software kann gehackt werden. Die Frage ist: Wie einfach machst du es? Mit den 7 Basics erschwerst du die häufigsten Angriffe erheblich. Für absolute Sicherheit gibt es keine Garantie — aber die Basics schließen 90% der Einfallstore.

Was passiert wenn Nutzerdaten geleakt werden?

Du bist als Betreiber haftbar. Laut DSGVO musst du den Vorfall innerhalb von 72 Stunden der Datenschutzbehörde melden und die betroffenen Nutzer informieren. Bußgelder können bis zu 20 Millionen Euro betragen. In der Praxis sind die Strafen für kleine Unternehmen geringer — aber der Reputationsschaden ist real.

Reicht Supabase-Security für ein Produkt?

Supabase liefert eine solide Basis: Passwort-Hashing, JWT-Tokens, RLS. Für einen Prototyp reicht das. Für ein Produkt mit zahlenden Kunden brauchst du zusätzlich: Rate Limiting, Monitoring, Audit Logs und professionelles Error Handling. Das ist Teil der Production-Ready Checklist.

Soll ich einen Security-Audit machen lassen?

Nicht für den Prototyp. Aber sobald du zahlende Kunden hast oder sensible Daten verarbeitest (Gesundheit, Finanzen, Personalakten), ist ein Security-Audit durch einen Profi sinnvoll. Kostet typischerweise 2.000–5.000 € und deckt Schwachstellen auf die du alleine nie findest.

Fazit: Security ist kein Feature — es ist eine Verantwortung

Du speicherst die Daten echter Menschen. E-Mail-Adressen, Passwörter, möglicherweise Geschäftsdaten. Das ist eine Verantwortung die mit dem ersten Nutzer beginnt — nicht erst mit dem tausendsten.

Die 7 Basics in diesem Artikel kosten dich 30 Minuten und schützen dich vor den häufigsten Angriffen. Für alles darüber hinaus brauchst du einen Profi der weiß, wie man Software baut die nicht nur funktioniert, sondern auch sicher ist.

Dein Prototyp funktioniert. Ist er auch sicher? Wir machen einen Security-Check und schließen die Lücken die AI Tools offen gelassen haben.

Jetzt Security-Check anfragen