Reeve Ist deine Bolt-App sicher?
Ist Bolt sicher genug zum Bauen? Der Code ist selten das Problem. Entscheidend ist, ob die Tabellen, die Bolt für dich schrieb, je abgeschlossen wurden.
Logos sind Eigentum ihrer jeweiligen Inhaber und dienen nur zur Kennzeichnung der Kompatibilität.
Kurz gesagt
- Eine Bolt-App ist auf der Code-Seite meistens sicher. Entscheidend ist, ob die von Bolt erzeugten Datenbanktabellen je abgeschlossen wurden.
- Tabellen, die per SQL entstehen, bekommen Row Level Security nicht standardmäßig, und SQL zu schreiben ist genau, wie Bolt sie anlegt.
- Ein öffentlicher Schlüssel in deiner App ist richtig. sb_secret_… oder service_role im Browser ist der, den du heute austauschst.
Bolt schreibt das ganze Projekt: die Bildschirme, die Verkabelung und die Datenbanktabellen darunter. Genau diesen letzten Teil bekommst du nie zu Gesicht, und dort beginnt fast jede Geschichte, die mit „meine Bolt-App verliert Daten" anfängt.
Hier ist der Punkt, den Anleitung um Anleitung falsch darstellt: Der Code, den Bolt geschrieben hat, ist selten das Problem. Das Problem ist meist ein einzelner Schalter pro Tabelle in deiner Datenbank, der nie eingeschaltet wurde, wegen der Art, wie die Tabellen entstanden, und nicht, weil jemand einen Fehler gemacht hätte.
Was Bolt einem Besucher aushändigt und was es behält
Zwei Hälften, und nur eine davon ist privat.
Stell es dir als Laden vor. Bolt baut dir eine Ladenfront (Seiten, Schaltflächen, Formulare), und diese Ladenfront wird jedem Besucher vollständig ausgehändigt, der deine Seite lädt. Das muss so sein. Ein Browser kann keine Seite anzeigen, die er nicht bekommen hat, also gibt es keine Variante, in der die Vorderseite deiner App geheim bleibt. Dahinter liegt ein Lager, deine Supabase-Datenbank, ein eigenes Gebäude mit eigenem Schloss.
Die Annahme, die Leute etwas kostet, ist, dass die Ladenfront das Lager steuert. Tut sie nicht. Deine Datenbank liegt mit eigener Adresse im Internet, und diese Adresse steht auf der Ladenfront, weil deine eigene App sie so erreicht. Wer deine veröffentlichten Dateien liest, liest auch die Adresse und kann dann mit dem Lager sprechen, ohne je durch deinen Laden zu gehen.
Ist es ein Problem, dass in meiner Bolt-App ein API-Schlüssel steckt?
Meistens nicht. Es hängt vollständig davon ab, welcher, und zwei davon sehen fast identisch aus.
Ein öffentlicher Schlüssel benennt dein Projekt und sonst nichts. Supabase
nennt ihn in neuen Projekten sb_publishable_… und in älteren anon, und er ist
dafür gebaut, in einem Browser zu liegen, wo ihn jeder lesen kann. Ein
geheimer Schlüssel (sb_secret_…, oder service_role vor der Umbenennung)
ist das Gegenteil. Er ignoriert jede Regel, die du geschrieben hast, und liest
und schreibt jede Zeile in jeder Tabelle.
Sie liegen im Supabase-Dashboard nebeneinander, sind ähnlich lang und verhalten sich beim Bauen identisch. Es geht nichts kaputt, wenn der falsche kopiert wird, und genau deshalb überlebt der Fehler bis in die Produktion. Die ausführliche Fassung, wie man sie unterscheidet, liest sich in etwa einer Minute.
Der Schalter, der entscheidet, wem deine Datenbank antwortet
Row Level Security ist eine Einstellung pro Tabelle in Supabase, die Zeile für Zeile entscheidet, wer was lesen darf. Aus, und dein öffentlicher Schlüssel gibt die ganze Tabelle zurück. An, mit geschriebener Policy, gibt er nur die Zeilen zurück, die diese Policy erlaubt.
Jetzt der Teil, der speziell für ein Bolt-Projekt gilt. Supabase aktiviert Row Level Security standardmäßig für Tabellen, die im Table Editor des Dashboards entstehen, dem zum Klicken. Tabellen, die per SQL angelegt werden, bekommen sie nicht und müssen bewusst aktiviert werden.
Bolt legt deine Tabellen an, indem es SQL schreibt.
Die übliche Gestalt eines Bolt-Projekts ist also ein Satz generierter Tabellen, die unabgeschlossen ankamen, neben allem, was du später von Hand hinzugefügt hast und was das nicht war. Die beiden sind im Editor nicht zu unterscheiden und funktionieren beide einwandfrei. Und die Einstellung zu aktivieren ist auch nicht die Ziellinie: Eine Tabelle mit eingeschalteter Row Level Security und einer Policy, die alle durchlässt, ist offen und meldet sich selbst als geschlossen.
So prüfst du deine eigene Bolt-App in etwa zehn Minuten
Lies deine Policy-Liste. In Supabase zeigt Authentication → Policies jede Tabelle mit dem Status von Row Level Security. Fang mit allem an, was als deaktiviert markiert ist; das ist für jeden lesbar, der deine Projektadresse hat.
Bestätige, welchen Schlüssel du ausgeliefert hast. Settings → API in Supabase zeigt beide. Der öffentliche in deiner App ist richtig und braucht nichts. Wurde je ein geheimer Schlüssel in das Projekt eingefügt, tausche ihn dort aus, bevor du deinen Code anfasst, denn die Zeile zu löschen schließt die Tür nicht, weil der alte Wert in jeder zwischengespeicherten Kopie deiner Seite überlebt.
Prüfe deine Storage-Buckets. Ein als öffentlich markierter Bucket kann von jedem aufgelistet und heruntergeladen werden, ob deine App je auf die Dateien darin verlinkt oder nicht.
Und dann schau von außen. Alles oben sagt dir, was konfiguriert ist. Es sagt dir nicht, was ein Fremder tatsächlich erreicht; das ist eine andere Frage, und die zählt. Unser kostenloser Scan liest deine Live-Seite so, wie es jeder Besucher täte, und gibt dir in etwa 20 Sekunden eine Note, ganz ohne Konto: App scannen.
Was zu tun ist
- Alles, was Bolt an einen Browser ausliefert, ist für jeden lesbar. So arbeiten Browser, und es zu verstecken ist kein Weg, der sich lohnt.
- Ein öffentlicher Schlüssel in deiner App ist richtig. Ein geheimer Schlüssel (
sb_secret_…oderservice_role) ist der, den du heute austauschst. - Tabellen, die per SQL entstehen, bekommen Row Level Security nicht standardmäßig, und SQL zu schreiben ist genau, wie Bolt Tabellen anlegt.
- Die Einstellung einzuschalten ist Schritt eins. Eine Policy, die alle erlaubt, lässt die Tabelle offen, während das Dashboard sie als geschützt zeigt.
- Dass deine App läuft, ist kein Beleg dafür, dass sie abgeschlossen ist. Von innen sehen beide Zustände identisch aus.
Öffne in Supabase Authentication → Policies und lies die Liste von oben nach unten. Steht dort irgendwo, dass Row Level Security deaktiviert ist, ist diese Tabelle der Anfang, und die Sicherheits-Checkliste in 10 Minuten deckt danach den Rest der Fläche ab.
Was bei einer Bolt-App tatsächlich schiefgehen kann
Nichts davon bedeutet, dass du etwas falsch gemacht hast: Es sind die üblichen Nebenwirkungen von schnellem Bauen. Das ist einen Blick wert:
Ein geheimer Schlüssel, der im Browser landet (die VITE_-Falle)
Bolt-Apps werden meist mit Vite gebaut, das eine Regel hat, die Leute überrascht: Jede Einstellung, deren Name mit VITE_ beginnt, wird in den Code eingebacken, der im Browser deines Besuchers läuft, wo ihn jeder lesen kann. Nenne ein echtes Geheimnis VITE_IRGENDWAS, und es geht an die Öffentlichkeit. Manche Schlüssel sollen öffentlich sein (wie ein Supabase-„anon“-Schlüssel), was in Ordnung ist: Reeve unterscheidet die sicheren von den gefährlichen, also keine Fehlalarme.
Deine Datenbank offen gelassen (Supabase-RLS aus)
Bolt verbindet deine App oft mit Supabase für die Daten. Supabase hat einen Schalter namens Row Level Security (RLS), der entscheidet, wer jede Zeile lesen oder ändern darf. Ist er aus, können deine Tabellen von jedem lesbar, oder änderbar, sein, der die Adresse findet. Es ist das häufigste ernste Problem in KI-gebauten Apps, und es ist unsichtbar, wenn du nicht nachprüfst.
Eine offengelegte .env- oder Konfigurationsdatei
Die .env-Datei enthält die Schlüssel und Passwörter eines Projekts. Manchmal wird sie versehentlich zusammen mit der deployten App veröffentlicht. Ist sie von außen erreichbar, ist sie eine Abkürzung zu allem Sensiblen. Reeve prüft, ob deine still zugänglich ist.
Öffentlicher Dateispeicher
Wenn Leute Dateien in deine App hochladen, leben diese in Speicher-„Buckets“. Ein öffentlich gelassener Bucket bedeutet, dass jeder auflisten oder herunterladen kann, was drin ist, sodass ein privater Upload für alle sichtbar werden kann. Reeve prüft, ob deine Buckets auflistbar sind; es lädt nie die Dateien von jemandem herunter.
Source Maps eingeschaltet gelassen
Eine „Source Map“ ist eine Hilfsdatei, die den Original-Code deiner App offenlegt. Praktisch beim Bauen, aber wenn sie in die Produktion geht, gibt sie Fremden eine lesbare Karte davon, wie deine App funktioniert, was jede andere Tür leichter auffindbar macht. Geringe Dringlichkeit, aber es lohnt sich, aufzuräumen.
Fehlende Sicherheits-Header & offene Endpunkte
Kleine Einstellungen, die Browsern sagen, wie sie deine Besucher schützen sollen, plus ob deine Daten-Endpunkte jedem oder jeder Website antworten. Allein geringfügig; zusammen vergrößern sie die Lücke. Reeve markiert die, die fehlen.
Was Reeve ist, und was nicht
Reeve ist eine kostenlose, nur-lesende Prüfung von außen, wie ein Inspektor, der ums Gebäude geht und die Türen probiert. Sie ist schnell und fängt die häufigen, folgenreichen Fehler ab. Sie ist kein vollständiges Sicherheitsaudit, und eine saubere Note ist keine Garantie. Sie bedeutet, dass die offensichtlichen Türen zu sind.
Bolt und StackBlitz verbessern laufend, was generiert wird, und wenn deine App Supabase nutzt, meldet Supabases eigener Berater Datenbankprobleme in seinem Dashboard. Beides hilft. Was Reeve ergänzt: Du lebst in Bolt, nicht in einem Dashboard, und diese Werkzeuge sprechen Entwickler. Reeve betrachtet deine ganze deployte App von außen, so, wie es ein Fremder täte, und sagt dir in Worten, mit denen du etwas anfangen kannst, was es findet. Und wenn du am liebsten nicht daran denken möchtest, können wir sie für dich im Blick behalten.
Willst du es erledigt, nicht nur geprüft?
Reeve Care behält deine App im Blick, sichert deine Daten und hilft dir, Dinge zu reparieren, wenn sie kaputtgehen, damit du weiterbauen kannst, statt dir Sorgen zu machen.
Mehr über Reeve Care erfahrenFAQ
Ist meine Bolt-App standardmäßig sicher?
Bolt gibt dir schnell eine funktionierende App, aber „standardmäßig sicher“ hängt davon ab, wie sie verdrahtet ist, besonders von deinen Umgebungsvariablen und, wenn du Supabase nutzt, deinen Datenbankregeln. Der einzige Weg, es zu wissen, ist zu prüfen, was tatsächlich offengelegt ist, und das macht Reeve kostenlos in etwa 20 Sekunden.
Warum ist mein API-Schlüssel in einer Bolt-App geleakt?
Meist, weil er in einer Einstellung gespeichert war, die mit VITE_ beginnt. Vite baut diese absichtlich ins Browser-Bundle ein, sodass jedes so benannte Geheimnis öffentlich wird. Reeve liest den geladenen Code deiner App, findet Schlüssel und sagt dir, welche sicher offenzulegen sind und welche auf den Server umziehen müssen.
Nutzt Bolt Supabase, und ist das sicher?
Bolt verbindet Apps häufig mit Supabase. Supabase ist sicher, wenn Row Level Security an ist und nur dein öffentlicher „anon“-Schlüssel im Frontend liegt. Ist RLS aus oder ein „service_role“-Schlüssel geleakt, können deine Daten offengelegt sein. Reeve prüft beides, ohne je deine tatsächlichen Daten zu lesen.
Ändert das Scannen meiner Bolt-App etwas?
Nein. Reeve sieht sich nur an, was von außen ohnehin öffentlich ist. Es loggt sich nie ein, ändert nie etwas und lädt nie deine Dateien herunter. Nur lesend, wie das Prüfen, ob eine Tür abgeschlossen ist, ohne einzutreten.
Bolt hat meine Datenbanktabellen geschrieben. Sind die standardmäßig abgeschlossen?
Oft nicht, und der Grund ist rein mechanisch. Supabase schaltet Row Level Security automatisch für Tabellen ein, die du im Table Editor zusammenklickst, aber nicht für Tabellen, die per SQL entstehen. Ein Builder legt Tabellen per SQL an, also kommen diese Tabellen mit ausgeschaltetem Schalter, es sei denn, jemand hat ihn danach eingeschaltet.
Die Vorschau lief und die veröffentlichte App läuft. Heißt das, alles ist richtig konfiguriert?
Nein, denn beides liefe so oder so. Eine App ohne Regeln auf ihrer Datenbank verhält sich exakt wie eine App mit korrekten Regeln, bis zu dem Moment, in dem jemand die Datenbank direkt abfragt statt durch deine Bildschirme zu gehen. Läuft ist nicht dieselbe Prüfung wie geschützt.
Wo sehe ich nach, ob mein Bolt-Projekt dieses Problem hat?
Öffne dein Supabase-Projekt und geh auf Authentication, dann Policies. Dort steht jede Tabelle des public-Schemas mit der Angabe, ob Row Level Security aktiv ist. Jede Tabelle, die als deaktiviert angezeigt wird, kann jeder lesen, der deine Projekt-URL und deinen öffentlichen Schlüssel hat, und beides steckt in der App, die du veröffentlicht hast.