Bolt
Bolt-App prüfen: wo die typischen Lücken liegen
Bolt baut Webanwendungen direkt im Browser und veröffentlicht sie mit einem Klick. So schnell wie der Weg zur fertigen App ist auch der Weg zur offenen App. Diese Stellen sollten Sie vor dem Livegang prüfen.
Wie eine Bolt-App aufgebaut ist
Bolt erzeugt meist eine JavaScript-Anwendung, oft mit React und Vite oder Next.js, und lässt sie in einer Entwicklungsumgebung im Browser laufen. Als Datenbank dient häufig Supabase oder die in Bolt integrierte Datenbank. Veröffentlicht wird über einen angebundenen Hosting-Dienst. Den Code können Sie herunterladen oder mit GitHub verbinden.
1. Umgebungsvariablen
Bolt legt Zugangsdaten in einer .env-Datei ab. Alles, was dort ein Präfix wie VITE_ trägt, landet beim Bauen im Browser-Code und ist öffentlich. Für den öffentlichen Supabase-Schlüssel ist das in Ordnung, für einen KI- oder Zahlungsschlüssel nicht. Prüfen Sie jede Variable einzeln. Mehr im Artikel API-Schlüssel im Frontend.
2. Datenbankrechte
Nutzt Ihre Bolt-App Supabase, gilt dasselbe wie bei jeder Supabase-Anwendung: Ohne Row Level Security und passende Regeln ist die Datenbank für jeden lesbar. Prüfen Sie jede Tabelle, auch die, die erst später dazukamen. Anleitung im Artikel Datenbankrechte bei Supabase und Firebase.
3. Anmeldung und geschützte Seiten
Geschützte Bereiche entstehen in Bolt-Apps oft als Weiche in der Oberfläche: Ist niemand angemeldet, wird auf die Anmeldeseite umgeleitet. Die Daten dieser Bereiche kommen aber aus der Datenbank oder aus Serverfunktionen. Sind diese nicht geschützt, hilft die Weiche nichts. Prüfen Sie in einem privaten Fenster, ob Anfragen ohne Anmeldung Daten liefern.
4. Testdaten und Testkonten
Während des Baus legt Bolt oft Beispieldaten und Testkonten an, manchmal mit einfachen Passwörtern. Löschen Sie beides, bevor die App öffentlich wird, und prüfen Sie, ob irgendwo ein voreingestelltes Admin-Konto existiert.
5. Abhängigkeiten
Bolt installiert Bibliotheken nach Bedarf. Laden Sie den Code herunter oder öffnen Sie ihn über GitHub und lassen Sie npm audit laufen. Kritische Treffer beheben Sie vor dem Launch.
Nach dem Veröffentlichen
Jede Veröffentlichung kann Regeln und Variablen verändern, wenn die KI vorher etwas umgebaut hat. Prüfen Sie die Punkte oben nach jeder grösseren Änderung erneut, nicht nur einmal. Die vollständige Liste steht in der Checkliste vor dem Launch eines KI-gebauten Produkts.
Bevor Sie damit live gehen
Ihre Lösung läuft. Diese Punkte sollten Sie prüfen, bevor echte Daten daran hängen:
- Enthält keine öffentliche Umgebungsvariable einen geheimen Schlüssel?
- Liefert die Datenbank ohne Anmeldung keine Daten, die nicht öffentlich sein sollen?
- Sind Testkonten und Beispieldaten vor dem Launch entfernt?
Sie wollen sicher sein? Das Vibe-Code-Review prüft genau diese Grundlagen. Mehr zum Review →
Lieber selbst anfangen? Die kostenlose Schnellprüfung aus dem Vibecode-Testing-Kit zeigt Ihnen, wo Sie stehen. Zur Schnellprüfung →
Sie haben schon gebaut? Lassen Sie es prüfen.
Beschreiben Sie Ihr Produkt in ein paar Sätzen. Ich melde mich persönlich.