Reeve Ist deine v0-App sicher?
Ist v0 sicher genug zum Bauen? Die erzeugten Komponenten sind nicht das Risiko. Die Verkabelung drumherum ist es, und ein Variablenname entscheidet fast alles.
Logos sind Eigentum ihrer jeweiligen Inhaber und dienen nur zur Kennzeichnung der Kompatibilität.
Kurz gesagt
- Eine v0-App lässt sich meist bedenkenlos veröffentlichen; die erzeugten Komponenten sind nicht das Risiko. Die Verkabelung drumherum ist es.
- Jede Variable namens NEXT_PUBLIC_… landet im JavaScript, das deine Besucher herunterladen. Für einen öffentlichen Schlüssel ist das richtig, für einen geheimen falsch.
- v0 setzt deine Datenbankregeln nicht. In Supabase starten Tabellen, die per SQL entstehen, ohne Row Level Security.
v0 gibt dir Komponenten: eine funktionierende Oberfläche, erzeugt und in dein Projekt gelegt. Was es dir nicht gibt, ist die Verkabelung dahinter: die Umgebungsvariablen, die Datenbank, die Regeln darüber, wer was lesen darf. In genau dieser Lücke geht ein v0-Projekt meist schief, und zwar leise.
Hier ist der Punkt, den Anleitung um Anleitung falsch darstellt: Der erzeugte Code ist nicht das Risiko. Das Risiko ist eine einzige Namenskonvention in deiner Umgebungsdatei und eine Datenbank-Einstellung, die mit v0 überhaupt nichts zu tun hat.
Welche Hälfte eines v0-Projekts öffentlich ist
Die Oberflächenhälfte, vollständig.
Stell es dir als Laden vor. Die Komponenten, die v0 schreibt, sind die Ladenfront (jede Seite, jedes Formular, jede Schaltfläche), und die ganze Ladenfront wird jedem Besucher ausgehändigt, der deine Seite lädt. Daran führt kein Weg vorbei; ein Browser kann keine Seite darstellen, die ihm nicht geschickt wurde. Dahinter liegt das Lager, deine Datenbank, ein eigenes Gebäude mit eigenem Schloss.
Was ein v0-Projekt besonders macht: Du setzt die beiden Hälften selbst zusammen. Die Komponenten kommen an, ohne etwas über deine Schlüssel oder deine Tabellen zu wissen, also ist jede Entscheidung darüber, was vom Lager zur Ladenfront hinüberwandert, deine eigene, meist in einer einzigen Datei voller Umgebungsvariablen.
Was NEXT_PUBLIC_ wirklich bedeutet
Es bedeutet „leg das in den Browser".
Next.js, wofür v0 erzeugt, entscheidet anhand des Variablennamens, was deine
Besucher bekommen. Alles, was NEXT_PUBLIC_IRGENDWAS heißt, wird in das
JavaScript kompiliert, das deine Seite ausliefert. Alles ohne dieses Präfix
bleibt auf dem Server. Dieselbe Regel gibt es unter anderen Namen in anderen
Werkzeugen: Vite benutzt ein VITE_-Präfix und sagt klar, dass diese Werte beim
Bauen in deinen Quellcode gebündelt werden, aber die Wirkung ist identisch: Das
Präfix veröffentlicht den Wert.
Für eine Projekt-URL oder einen öffentlichen Schlüssel ist das genau richtig. Für einen geheimen ist es genau falsch.
Die Falle hat eine wiedererkennbare Form. Irgendetwas in der Oberfläche kann
einen Wert nicht lesen, also wird das Präfix ergänzt, damit der Fehler
verschwindet, und er verschwindet, die App läuft. War der Wert ein
Supabase-Schlüssel sb_publishable_… oder der ältere anon, ist nichts falsch.
War es sb_secret_… oder service_role, war der Fehler das System, das dir
sagte, dieser Code gehört auf einen Server, und die Umbenennung hat einen
Schlüssel veröffentlicht, der jede von dir gesetzte Regel ignoriert.
Die beiden zu unterscheiden
dauert etwa eine Minute und lohnt sich einmal für jeden Schlüssel in der Datei.
Was entscheidet, ob Fremde deine Daten lesen können
Deine Datenbankregeln, nicht deine Komponenten.
Liegen deine Daten in Supabase, heißt die Einstellung Row Level Security: ein Schalter pro Tabelle, der Zeile für Zeile entscheidet, wer was lesen darf. Ist er aus, gibt dein öffentlicher Schlüssel jedem, der fragt, die ganze Tabelle. Ist er an und eine Policy geschrieben, gibt er nur zurück, was die Policy erlaubt.
Supabase schaltet ihn standardmäßig für Tabellen ein, die im Table Editor des Dashboards entstanden sind, und nicht für Tabellen, die per SQL angelegt wurden. Die Tabellen, die du zusammengeklickt hast, sind also meist geschützt, und jede Tabelle aus einer Migrationsdatei womöglich nicht. Hinterher sehen beide gleich aus, und beide funktionieren.
Es gibt eine zweite Variante davon, die Leute erwischt, die alles richtig gemacht haben: Eine Tabelle kann Row Level Security aktiviert haben und trotzdem wegen ihrer Policy für alle offen sein. Aktiviert und geschützt sind zwei verschiedene Zustände.
So prüfst du dein eigenes v0-Projekt in etwa zehn Minuten
Lies deine Umgebungsdatei Zeile für Zeile. Jede Variable mit dem Präfix
NEXT_PUBLIC_ ist veröffentlicht. Frag dich bei jeder: Wäre es mir recht, das
auf der Startseite abzudrucken? Wenn nicht, gehört sie nicht zu diesem Präfix.
Tausche alles aus, was dort nie hätte stehen dürfen. Erzeuge im Dashboard deines Anbieters einen neuen Schlüssel und widerrufe den alten. Die Zeile aus dem Code zu entfernen schließt die Tür nicht, denn der alte Wert steckt weiterhin in deiner Versionsgeschichte und in zwischengespeicherten Kopien der Seite.
Prüfe deine Tabellenregeln. In Supabase listet Authentication → Policies jede Tabelle mit dem Status von Row Level Security. Alles Deaktivierte ist für jeden lesbar, der deine Projektadresse hat.
Und dann schau von außen. Die Schritte oben sagen dir, was konfiguriert ist; sie sagen dir nicht, was tatsächlich erreichbar ist. Unser kostenloser Scan liest deine Live-Seite so, wie es ein Besucher täte, und gibt dir in etwa 20 Sekunden eine Note, ganz ohne Konto: App scannen.
Was zu tun ist
NEXT_PUBLIC_ist keine Formalie. Es kompiliert den Wert in die Dateien, die jeder Besucher herunterlädt.- Das Präfix zu ergänzen, um einen Fehler verstummen zu lassen, ist der Moment zum Innehalten und Nachsehen, was der Wert eigentlich ist.
- Ein öffentlicher Schlüssel gehört in den Browser.
sb_secret_…undservice_roleniemals. - v0 setzt deine Datenbankregeln nicht. In Supabase starten Tabellen, die per SQL entstehen, ohne Row Level Security.
- Eine Tabelle mit aktivierter Row Level Security kann trotzdem für alle offen sein. Entscheidend ist die Policy.
Öffne deine Umgebungsdatei und lies die NEXT_PUBLIC_-Zeilen laut vor. Steht in
einer davon etwas, das du nicht auf deine Startseite drucken würdest, tausche es
jetzt aus, und danach deckt die
Sicherheits-Checkliste in 10 Minuten ab, was in einem frisch
gestarteten Projekt sonst noch abzuschalten ist.
Was bei einer v0-App tatsächlich schiefgehen kann
Nichts davon ist deine Schuld: Es sind die normalen Nebenwirkungen davon, Code schnell zu generieren. Das ist einen Blick wert:
Ein geheimer Schlüssel in einer Client-Komponente (die NEXT_PUBLIC_-Falle)
v0 baut mit Next.js, das eine Regel hat, über die Leute stolpern: Alles, was NEXT_PUBLIC_ heißt, und jeder Schlüssel, der direkt in eine Client-Komponente geschrieben wird, wird an den Browser gesendet, wo ihn jeder lesen kann. Es ist leicht, einen API-Schlüssel in eine generierte Komponente zu kleben, ohne zu merken, dass er jetzt öffentlich ist. Manche Schlüssel sollen öffentlich sein; Reeve unterscheidet die von denen, die es nicht sollen, also keine Fehlalarme.
Deine Datenbank offen gelassen (Supabase-RLS aus)
Wenn deine v0-App Daten speichert (oft in Supabase), gibt es einen Schalter namens Row Level Security (RLS), der entscheidet, wer jede Zeile lesen oder ändern darf. Ist er aus, können deine Tabellen für jeden offen sein, der die Adresse findet. Es ist das häufigste ernste Problem in generierten Apps und bleibt unsichtbar, bis du nachsiehst.
Veröffentlichte Source Maps
Eine „Source Map“ legt den Original-Code deiner App jedem offen, der die Browser-Tools öffnet. Sie ist beim Bauen hilfreich, aber wenn sie in die Produktion geht, gibt sie Fremden eine lesbare Kopie davon, wie deine App funktioniert, und macht jede andere Lücke leichter auffindbar. Reeve prüft, ob deine offengelegt sind.
Offene API-Routen
Next.js-Apps enthalten oft API-Routen: kleine Endpunkte, die Dinge tun wie Daten lesen oder schreiben. Wurde eine ohne Auth-Prüfung generiert, antwortet sie vielleicht jedem, der sie aufruft. Reeve prüft, ob deine Endpunkte Fremden antworten, ohne sie je zu nutzen, um etwas zu ändern.
Eine offengelegte .env- oder Konfigurationsdatei
Die .env-Datei enthält die Schlüssel eines Projekts. Gelegentlich wird sie versehentlich mit der deployten App veröffentlicht, und ist sie erreichbar, ist sie eine Abkürzung zu allem Sensiblen. Reeve prüft, ob deine still zugänglich ist.
Fehlende Sicherheits-Header & offene Freigabe (CORS)
Kleine Einstellungen, die Browsern sagen, wie sie Besucher schützen sollen, und ob irgendeine Website die Daten deiner App aufrufen darf. Allein geringfügig; zusammen vergrößern sie die Lücke. Reeve markiert, was fehlt.
Was Reeve ist, und was nicht
Reeve ist eine kostenlose, nur-lesende Prüfung von außen, wie ein Inspektor, der die Türen probiert, ohne einzutreten. 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.
v0 und Vercel heben laufend die Qualität dessen, was generiert und deployt wird, und wenn du Supabase nutzt, meldet dessen eigener Berater Datenbankprobleme im Dashboard. Beides hilft. Was Reeve ergänzt: Du arbeitest in v0, liest nicht den generierten Code Zeile für Zeile, und diese Werkzeuge sprechen Entwickler. Reeve betrachtet die ganze deployte App von außen und sagt dir in verständlichen Worten, 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 v0-Code produktionsreif und sicher?
v0 erzeugt sauberen, modernen Code, aber „sieht produktionsreif aus“ ist nicht dasselbe wie „geprüft“. Sicherheit hängt davon ab, wie die App verdrahtet ist: wo Schlüssel liegen, ob deine Datenbankregeln an sind, ob Endpunkte geschützt sind. Reeve prüft die offengelegten Teile kostenlos in etwa 20 Sekunden.
Kann eine v0-App meine API-Schlüssel offenlegen?
Ja, wenn ein Schlüssel in einer Client-Komponente oder einer NEXT_PUBLIC_-Einstellung landet, sendet Next.js diese an den Browser. Nicht jeder Schlüssel ist ein Problem: Manche sollen öffentlich sein. Reeve findet die Schlüssel in deinem geladenen Code und sagt dir, welche sicher sind und welche auf den Server umziehen müssen.
Sind v0-API-Routen sicher?
Sie können es sein, aber ein generierter Endpunkt geht manchmal ohne Authentifizierungsprüfung raus, was bedeutet, dass jeder, der ihn findet, ihn aufrufen kann. Reeve testet, ob deine Endpunkte Fremden antworten; es prüft nur, ob die Tür aufgeht, geht aber nie hindurch.
Bricht das Scannen meiner v0-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 Daten herunter. Nur lesend, wie das Prüfen, ob eine Tür abgeschlossen ist, ohne hineinzugehen.
Was macht das Präfix NEXT_PUBLIC_ eigentlich?
Es sagt Next.js, diesen Wert in das JavaScript zu kompilieren, das an den Browser geht. Der Wert ist damit keine serverseitige Einstellung mehr, sondern Teil deiner veröffentlichten Dateien und für jeden Besucher lesbar. Für einen öffentlichen Schlüssel ist das richtig, für einen geheimen falsch, und das Präfix ist das Einzige, was darüber entscheidet.
Ich habe eine Variable umbenannt und NEXT_PUBLIC_ ergänzt, weil die App sie nicht lesen konnte. War das ein Fehler?
Das hängt ganz davon ab, was in der Variable steht. War es ein öffentlicher Schlüssel oder eine Projekt-URL, war die Umbenennung genau die richtige Lösung. War es ein geheimer Schlüssel, konnte die App ihn nicht lesen, weil er nie im Browser laufen sollte, und die Umbenennung hat ihn veröffentlicht. Tausche diesen Schlüssel aus und verschiebe den Code, der ihn brauchte, in eine Server-Route.
Konfiguriert v0 meine Datenbankregeln für mich?
Nicht von selbst. v0 erzeugt Oberflächencode; die Datenbank und ihre Regeln richtest du dort ein, wo du sie hostest. Bist du bei Supabase, ist Row Level Security nur für Tabellen standardmäßig an, die im Table Editor des Dashboards entstanden sind, und aus für Tabellen, die per SQL angelegt wurden.