Zum Inhalt springen

Sicherheit von Prototypen aus KI-Tools

Sieht ein Kunde die Daten eines anderen?

Die Sicherheit Ihres Prototyps mit Supabase oder Firebase prüfen Sie mit acht Checks. Sie sehen die Risikostufe, was Sie zuerst beheben, und einen Prompt, mit dem ein Agent das in Ihrem Code prüft.

Check startenOder ein 15-minütiges Erstgespräch
In 2 MinutenPrompt für Cursor und Claude Code
Filip Papranec
Filip Papranec
Gründer von Digitaliko

Schicken Sie uns Ihren Prototyp.

Ein Prototyp aus Lovable oder Cursor ist ein guter Anfang, kein Grund zur Scham. Schicken Sie uns den Link zum Repo und kurz, was die App macht. Innerhalb von 10 Arbeitstagen sagen wir Ihnen offen, ob Sie darauf aufbauen können.

  1. 1Innerhalb von zwei Arbeitstagen melden wir uns mit einem Starttermin für das Audit. Sie schreiben direkt den Leuten, die es bauen.
  2. 2Lesezugriff auf den Code reicht, Kundendaten fassen wir nicht an.
  3. 3Das Urteil haben Sie innerhalb von 10 Arbeitstagen ab Zugang zum Code, die erste Korrektur als PR in Ihrem Repo.

Oder ein 15-minütiges Erstgespräch

Sieht ein Kunde die Daten eines anderen? Prototyp-Check in 2 MinutenCheck mit Prompt für Ihren Agenten. Sie senden nichts ab.

Haken Sie nur an, was Sie geprüft haben. Wo Sie es nicht wissen, lassen Sie das Feld leer. Unter dem Ergebnis steht ein Prompt, mit dem Cursor oder Claude Code das in Ihrem Code prüft.

A. Daten

B. Login

C. Secrets

Lassen Sie es von einem Agenten prüfen

Fügen Sie den Prompt in Cursor oder Claude Code im Stammverzeichnis des Projekts ein. Der Agent ändert nichts, er listet nur die Befunde mit Datei und Zeile auf.

Prüfe die Sicherheit dieses Projekts. Ändere nichts, liste nur die Befunde mit Datei und Zeile auf.
1. Datenbank: Hat jede Tabelle RLS (Supabase) oder Security Rules (Firebase) mit einer Regel auf den Eigentümer des Datensatzes? Liste Tabellen ohne Regeln und Regeln vom Typ "true" oder nur "auth.uid() is not null" auf.
2. Code für den Browser: Finde Variablen mit dem Präfix NEXT_PUBLIC_, VITE_, EXPO_PUBLIC_ und Schlüssel im Code. Ist darunter service_role, ein secret oder ein Schlüssel mit Schreibrechten?
3. Jede API-Route, Server Action und Edge Function: Prüft sie Login und Eigentümer des Datensatzes auf dem Server? Nimmt sie die Nutzer-ID aus der Session, nicht aus dem Request-Body?
4. Admin-Aktionen: Prüft der Server die Rolle, oder wird nur ein Button in der UI ausgeblendet?
5. Storage: Sind Buckets mit Kundendateien öffentlich?
6. Repository: Gibt es darin oder in der Historie .env-Dateien oder Schlüssel? Starte gitleaks, falls verfügbar.
Sortiere die Befunde am Ende nach Risiko, das größte zuerst, und schreibe zu jedem die Korrektur in einem Satz.

Wir verwenden die Formulardaten nur zur Beantwortung Ihrer Anfrage. Mehr dazu in unserer Datenschutzerklärung.

Häufige Fragen

Für welche Apps ist der Check gedacht?
Für Apps aus Lovable, Cursor, Bolt oder Claude Code mit einer Supabase- oder Firebase-Datenbank, in denen Kunden eigene Daten haben.
Ersetzt das ein Audit?
Nein. Der Check zeigt die häufigsten offenen Türen. Ein Audit geht den ganzen Code, das Deployment und die Backups durch und macht die erste Korrektur direkt in Ihrem Repo.
Speichern Sie meine Antworten?
Nein. Der Check läuft nur in Ihrem Browser und Sie senden nichts ab. Ihren Code und Ihre Daten fassen wir nicht an.