Free Security-Check für deine AI-gebaute App

Du willst wissen, ob deine AI-gebaute App sicher ist. Aber du willst nicht gleich Geld ausgeben. Verständlich.

Dieser Artikel gibt dir fünf konkrete Checks, die du selbst durchführen kannst. Ohne Programmierkenntnisse, ohne Tools, in etwa 15 Minuten. Sie decken nicht alles ab — aber sie finden die größten und häufigsten Probleme.

Wenn du danach beruhigt bist: gut. Wenn nicht: Dann weißt du zumindest, wo du stehst.

Bevor du anfängst

Du brauchst:

• Zugang zu deinem Supabase-Dashboard (wenn deine App Supabase nutzt)
• Zugang zu deinem GitHub-Repository (oder den Quellcode deiner App)
• Zwei verschiedene E-Mail-Adressen für Testaccounts
• Einen modernen Browser (Chrome, Firefox, Edge)
• 15 Minuten ungestörte Zeit

Bereit? Los geht's.

Check 1: Offene Datenbank-Tabellen

Was du prüfst: Ob jemand von außen auf deine Supabase-Datenbank zugreifen kann, ohne eingeloggt zu sein.

So geht's:

1. Öffne dein Supabase-Dashboard unter supabase.com
2. Gehe zu deinem Projekt
3. Klicke auf "Table Editor" in der linken Seitenleiste
4. Für jede Tabelle: Klicke auf die Tabelle, dann auf "RLS" (oben rechts) oder gehe zu Authentication > Policies

Was du sehen willst:

• RLS ist aktiviert (Schalter auf "on")
• Es gibt mindestens eine Policy pro Tabelle

Rotes Warnsignal:

• RLS ist deaktiviert bei einer Tabelle, die Nutzerdaten enthält
• RLS ist aktiviert, aber es gibt keine Policies (das blockiert alle Zugriffe — auch legitime)

Warum das wichtig ist: 170 von 1.645 Lovable-Apps hatten offene Datenbanken. Wenn deine Tabelle keine RLS-Policy hat und RLS deaktiviert ist, kann jeder mit deiner Supabase-URL alle Daten lesen.

Bewertung:

• Alle Tabellen haben RLS + Policies → Grünes Licht für diesen Check
• Eine oder mehr Tabellen ohne RLS → Sofort handeln

Check 2: API-Keys im Quellcode

Was du prüfst: Ob geheime Zugangsdaten im Quellcode stehen — sichtbar für jeden mit Zugang zum Repository.

So geht's:

1. Öffne dein GitHub-Repository (oder deinen lokalen Code)
2. Nutze die Suchfunktion (auf GitHub: oben links, dann "Search in this repository")
3. Suche nacheinander nach diesen Begriffen:
   • sk_live_ (Stripe Live Key)
   • sk_test_ (Stripe Test Key)
   • service_role (Supabase Service Role Key)
   • apikey oder api_key
   • secret
   • password
   • token

Was du sehen willst: Keine Treffer. Oder nur Treffer in .env.example-Dateien mit Platzhaltern.

Rotes Warnsignal:

• Du findest lange Zeichenketten, die wie echte Keys aussehen (z.B. sk_live_51J3...)
• Keys stehen in .ts, .js, .tsx oder .jsx Dateien
• Besonders kritisch: Stripe Secret Key oder Supabase Service Role Key im Code

Warum das wichtig ist: Ein Stripe Secret Key erlaubt es, Zahlungen auszulösen und Kundendaten einzusehen. Ein Supabase Service Role Key umgeht alle Sicherheits-Policies. Beides kommt regelmäßig in AI-generiertem Code vor.

Bewertung:

• Keine Keys gefunden → Grünes Licht
• Keys gefunden → Sofort in Umgebungsvariablen verschieben. Kompromittierte Keys rotieren (alte ungültig machen, neue erstellen)

Bonus-Check: Ist dein GitHub-Repository öffentlich oder privat? Wenn öffentlich: Alles im Code ist für die ganze Welt sichtbar. Überlege, ob es privat sein sollte.

Check 3: Autorisierung zwischen Nutzern

Was du prüfst: Ob ein eingeloggter Nutzer auf die Daten eines anderen Nutzers zugreifen kann.

So geht's:

1. Erstelle zwei Testaccounts in deiner App (Account A und Account B)
2. Logge dich mit Account A ein
3. Erstelle ein paar Testdaten (ein Projekt, einen Eintrag, was auch immer deine App anbietet)
4. Schaue dir die URL an, wenn du die Daten von Account A ansiehst. Sie enthält wahrscheinlich eine ID (z.B. /projekte/abc123)
5. Kopiere diese URL
6. Logge dich aus und mit Account B ein
7. Füge die kopierte URL in die Adressleiste ein

Was du sehen willst: Eine Fehlermeldung oder eine Weiterleitung. Account B sollte die Daten von Account A nicht sehen können.

Rotes Warnsignal:

• Account B sieht die Daten von Account A
• Account B kann die Daten von Account A sogar bearbeiten oder löschen

Warum das wichtig ist: Das ist die häufigste übersehene Sicherheitslücke in AI-gebauten Apps. Der Login funktioniert, aber die Zugriffskontrollen dahinter fehlen.

Bewertung:

• Account B kann keine fremden Daten sehen → Grünes Licht
• Account B sieht fremde Daten → Kritisch. Ein Entwickler muss Autorisierungsprüfungen einbauen

Check 4: Fehlerverhalten

Was du prüfst: Ob deine App sinnvoll reagiert, wenn etwas schiefgeht — oder ob sie einfach abstürzt.

So geht's:

1. Schicke ein leeres Formular ab (ohne Pflichtfelder auszufüllen)
2. Gib absichtlich ungültige Daten ein (zu langes Passwort, Sonderzeichen, extrem lange Texte)
3. Öffne deine App und schalte dann dein Internet aus. Versuche eine Aktion auszuführen
4. Öffne die Browser-Konsole (F12 → Console Tab) und nutze die App normal. Achte auf rote Fehlermeldungen

Was du sehen willst:

• Verständliche Fehlermeldungen für den Nutzer
• Kein weißer Bildschirm
• Keine kryptischen Fehlertexte
• Die App fängt sich nach dem Fehler wieder

Rotes Warnsignal:

• Weißer Bildschirm bei fehlerhaften Eingaben
• Unbehandelte Fehler in der Browser-Konsole
• App friert ein oder wird nach einem Fehler unbenutzbar

Warum das wichtig ist: Echte Nutzer machen Dinge, die du nicht erwartest. Wenn deine App bei unerwarteten Eingaben abstürzt, verlierst du Nutzer — und im schlimmsten Fall Daten.

Bewertung:

• App zeigt sinnvolle Fehlermeldungen → Gut
• App stürzt ab oder zeigt weiße Seiten → Fehlerbehandlung muss nachgerüstet werden

Check 5: HTTPS und Security-Headers

Was du prüfst: Ob die Verbindung zu deiner App verschlüsselt ist und ob grundlegende Schutzheader gesetzt sind.

So geht's:

1. Öffne deine App im Browser
2. Schaue in die Adressleiste: Steht dort https:// und ein Schloss-Symbol?
3. Öffne die Browser-Konsole (F12)
4. Gehe zum Tab "Network" (Netzwerk)
5. Lade die Seite neu
6. Klicke auf die erste Anfrage (den HTML-Seitenaufruf)
7. Schaue unter "Response Headers" nach diesen Einträgen:
   • content-security-policy
   • x-frame-options
   • strict-transport-security
   • x-content-type-options

Was du sehen willst: HTTPS aktiv und mindestens zwei der genannten Headers vorhanden.

Rotes Warnsignal:

• Kein HTTPS (Verbindung nicht verschlüsselt)
• Keiner der Security-Headers ist vorhanden
• Browser zeigt Warnungen an

Warum das wichtig ist: Keine einzige getestete Vibe-Coding-App hatte Security-Headers. Sie sind eine grundlegende Verteidigungslinie, die wenig Aufwand erfordert — aber großen Schutz bietet.

Bewertung:

• HTTPS aktiv + Headers vorhanden → Sehr gut
• HTTPS aktiv, aber keine Headers → Verbesserung empfohlen
• Kein HTTPS → Sofort handeln

Dein Ergebnis auswerten

Zähle deine grünen Lichter und roten Warnsignale:

5 grüne Lichter: Deine App besteht die Basis-Checks. Das bedeutet nicht, dass sie perfekt ist — es gibt tiefere Probleme, die nur ein professioneller Audit findet (SSRF, SQL-Injection, Rate-Limiting). Aber die größten offenen Türen sind geschlossen.

3–4 grüne Lichter: Du bist auf einem guten Weg, aber es gibt konkrete Lücken. Behebe die gefundenen Probleme, bevor du live gehst.

0–2 grüne Lichter: Deine App hat ernsthafte Sicherheitsprobleme. Das ist kein Vorwurf — es ist der Normalfall bei AI-generiertem Code. Aber es bedeutet, dass du vor einem Go-Live professionelle Hilfe brauchst.

Was dieser Check nicht abdeckt

Dieser Self-Check findet die offensichtlichsten Probleme. Was er nicht findet:

• Server-Side Request Forgery (SSRF) — erfordert technisches Testing
• SQL-Injection — erfordert gezielte Angriffsversuche
• Rate-Limiting-Lücken — erfordert Lasttests
• Business-Logic-Fehler — erfordert Verständnis der App-Logik
• DSGVO-Konformität — erfordert rechtliche und technische Prüfung
• Kryptografie-Schwächen — erfordert Analyse der Verschlüsselungsimplementierung

Für eine vollständige Prüfung brauchst du einen professionellen Security-Audit. Aber dieser Self-Check gibt dir eine ehrliche Basis.

Der nächste Schritt

Du hast jetzt ein Bild davon, wo deine App steht. Wenn du unsicher bist oder Probleme gefunden hast, gibt es zwei Optionen:

Option 1: Selber fixen. Die Checks oben zeigen dir, was zu tun ist. Für RLS-Policies und Secrets-Management gibt es gute Dokumentation bei Supabase.

Option 2: Professionell prüfen lassen. Ein vollständiger Security-Audit und Cleanup findet und behebt alles — auch die Dinge, die dieser Self-Check nicht abdeckt.

Willst du einen vollständigen Check? Schick mir den Link zu deiner App oder deinem GitHub-Repo. 30 Minuten Erstgespräch, kostenlos, ohne Verpflichtung.

Erstgespräch vereinbaren