v0-Sicherheit: alle 1.790 gescannten v0-Apps bekamen ein A

Du hast v0 eine App beschrieben, zugesehen, wie es eine baut, und einen Link bekommen, der auf vusercontent.net endet. Sie funktioniert, sie sieht fertig aus, und vielleicht hast du sie schon jemandem geschickt. Bevor echte Kunden ihre Daten eintippen, hast du nach v0-Sicherheit gesucht, und ein Teil dessen, was zurückkam, war eine Geschichte über Angreifer, die mit v0 gefälschte Anmeldeseiten bauen.

Diese Geschichte handelt davon, was andere Leute mit dem Werkzeug machen. Dieser Beitrag handelt von der App, die du damit gemacht hast, und dafür haben wir eine Messung. Zwischen dem 12. und 14. August 2026 haben wir dieselben neun externen Checks, die jeder kostenlos auf unserer Startseite laufen lassen kann, über 30.998 laufende Apps laufen lassen, und 1.790 davon waren v0-Apps. Jede der 1.790 bekam ein A.

Hier ist der Teil, den eine Rangliste falsch versteht: Dieses A sagt mehr darüber, was es zu prüfen gab, als über v0. Als Rangliste gelesen macht es v0 zum sichersten Builder, den wir gemessen haben. Mit seinen Nennern gelesen beschreibt es Frontends, hinter denen nichts steht, und es hört an dem Tag auf, deine App zu beschreiben, an dem du eine Datenbank verbindest.

Ist v0 sicher?

Bei allem, was wir über v0 selbst messen konnten, ja. Sein einziger Fund gehört zu der Domain, von der v0 deine App ausliefert, und sonst tauchte bei keiner der 1.790 in keinem der neun Checks etwas auf. Was das nicht sagen kann, ist, wie sich deine App verhält, sobald sie Daten hält, denn fast keine davon hielt welche.

Stell dir eine v0-Vorschau als Aktenschrank in einem Ausstellungsraum vor. Die Schubladen gleiten, die Etiketten sind dran, jeder, der vorbeikommt, kann eine aufziehen, und jede Schublade ist leer. Unsere Checks haben jede Schublade probiert und in keiner etwas gefunden, und das ist ein zutreffender Bericht über einen leeren Schrank.

Wie leer, steht in den Zahlen. Nur 17 der 1.790 nannten irgendwo in ihrem ausgelieferten Code ein Supabase-Projekt, und bei allen 17 bekam unser Datenbank-Check keine Antwort, die er beurteilen konnte, also steht die Zahl lesbarer Tabellen auf v0 bei null von null. Jede der 1.790 wurde von vusercontent.net ausgeliefert, das Vercel in seinem Antrag an die Public Suffix List als den Ort beschreibt, "an dem wir die von Nutzern eingereichten Inhalte hosten". Eine App, die du veröffentlichst, landet auf einer vercel.app-Adresse oder einer eigenen Domain, wo von außen nichts sie als v0 kennzeichnet, also sind diese nicht mitgezählt. Methode und vollständige Daten stehen im Bericht.

"Ist v0 sicher" sind also drei Fragen:

1. Das Werkzeug. Was v0 im Code prüft, den es schreibt, und was es nicht veröffentlicht. Dieser Teil ist Vercels Sache, und er ist dokumentiert.
2. Die Vorschau. Der Schrank im Ausstellungsraum, unter seiner vusercontent.net-Adresse. Jede App, die wir gemessen haben, war in diesem Stadium.
3. Die App, die du füllst. Derselbe Code, sobald er die Daten deiner Kunden hält oder auf einer eigenen Domain läuft. Fast nichts, was wir gemessen haben, war so weit.

Was die v0-Sicherheit abdeckt, bevor du veröffentlichst

Drei Dinge, und v0s eigene Dokumentation benennt jedes davon.

Es liest den Code, den es geschrieben hat. v0s Sicherheitsseite sagt, dass jeder generierte Code "vor der Ausführung eine Sicherheitsanalyse durchläuft" und dass v0 "die Nutzung von NEXT_PUBLIC_ analysiert und vor möglichen Sicherheitsrisiken warnt". NEXT_PUBLIC_ ist das Präfix, das Next.js, dem Framework, in dem v0 schreibt, sagt, einen Wert in den Code zu legen, den jeder Besucher lädt. Was dieses Präfix mit einem Schlüssel macht ist ein eigener Beitrag.

Es verweigert manche Deployments. Im August 2025 schrieb Vercel, v0 habe in den vorangegangenen 30 Tagen über 17.000 Deployments allein wegen offengelegter Secrets blockiert, und seit dem Start über 100.000 unsichere Deployments. Das sind Vercels Zahlen über Vercels Sperre, und die gilt für Deployments auf Vercel. Ein Teil unserer Null kann auf diese Sperre zurückgehen. Wie viel, können wir von außen nicht sagen.

Die Supabase-Integration setzt das Präfix an die richtige Stelle. Über den Vercel Marketplace verbunden, legt sie ein Dutzend Umgebungsvariablen an, und nur zwei davon tragen NEXT_PUBLIC_: die Projektadresse und der veröffentlichbare Schlüssel, die beide öffentlich sein sollen. SUPABASE_SECRET_KEY und das Datenbankpasswort bleiben ohne Präfix auf dem Server.

Warum einer v0-Vorschau Security-Header fehlen

Weil die Vorschaudomain von v0 sie setzt, bekommt jede App darauf dieselbe Antwort, und aus einer Vorschau heraus kannst du das nicht ändern.

Security-Header sind Anweisungen, die eine Website mit jeder Seite mitschickt: immer HTTPS benutzen, keine andere Website darf diese Seite in ihre eigene einbetten, nicht raten, welche Art Datei das ist. Wer die Seite ausliefert, schickt sie. Die Vorschauen, die wir am 3. Oktober 2026 geöffnet haben, schickten einen der fünf, nach denen unser Check sucht, den, der HTTPS erzwingt, und keinen der anderen vier. Das ist der Fund bei allen 1.790 v0-Apps, und er ist der einzige.

Der Ausstellungsraum bestimmt seine eigenen Türen und Alarmanlagen, und du kannst sie nicht für einen einzelnen Schrank darin umverdrahten. Sobald du veröffentlichst, steht der Schrank in deinem Büro, und die Header sind eine Einstellung in vercel.json oder in deiner Next.js-Konfiguration. Was jeder Header tut, und die zwei, die nichts kosten, ist ein eigener Artikel.

Ist eine vusercontent.net-Vorschau öffentlich?

Behandle sie als öffentlich. Jeder, der die Adresse hat, kann sie öffnen, und Adressen wandern.

Jede der 1.790 öffnete sich für uns ohne Anmeldung, und wir mussten keine davon erraten: Ihre Adressen stammten aus einem öffentlichen Webarchiv, das von jeder schon eine Kopie gespeichert hatte. v0s Freigabe-Einstellungen entscheiden, wer deinen Chat sehen kann: standardmäßig privat, dann dein Team, jeder mit dem Link oder jeder im Web. Die Dokumentation sagt nicht, dass diese Einstellungen bis zur Vorschau reichen.

Eine Vorschau ist also der Schrank im Ausstellungsraum. Das passt, um jemandem das Design zu zeigen, und nicht für die echten Unterlagen von irgendwem. Vercel hat vusercontent.net im September 2024 auf die Public Suffix List gesetzt, wodurch Browser jede Vorschau als eigene Website behandeln, also kann eine Vorschau keine Cookies für alle anderen setzen. Das hält Vorschauen voneinander getrennt, und es trägt nichts dazu bei, deine privat zu halten.

Falls du hier bist, weil dir jemand einen vusercontent.net-Link geschickt hat: Die Domain gehört Vercel, und die Seite darauf hat gebaut, wer sie per Prompt erstellt hat. Am 1. Juli 2025 berichtete Okta von Angreifern, die mit v0 Kopien echter Anmeldeseiten bauten, und Vercel hat den Zugriff auf die gefundenen eingeschränkt. Tippe kein Passwort in ein Anmeldeformular unter so einer Adresse, wenn du es nicht erwartet hast.

Was sich ändert, wenn du Supabase mit v0 verbindest

Du fängst an, die Schubladen zu füllen, und die Checks, die bei v0 leer zurückkamen, haben plötzlich etwas zu prüfen.

v0 fügt Supabase mit einem Klick hinzu und "kann", in den Worten seiner eigenen Dokumentation, "SQL erzeugen und ausführen. Damit kannst du Tabellen anlegen, ändern und löschen." So entstehen deine Tabellen. Jede Tabelle ist eine Schublade, und Row Level Security ist das Schloss daran: eine Einstellung pro Tabelle, die entscheidet, welche Zeilen der veröffentlichbare Schlüssel in deiner Seite lesen darf. Dieser Schlüssel soll öffentlich sein, also entscheidet allein das Schloss, was ein Fremder zurückbekommt.

Supabase baut dieses Schloss standardmäßig in Tabellen ein, die im Table Editor angelegt werden, und lässt es bei Tabellen weg, die per SQL angelegt werden, und genau so legt v0 sie an.

Dort landeten die ernsten Funde bei jedem anderen Builder. Von den 3.553 Lovable-Apps, deren Datenbank wir fragen konnten, gaben 2.017 Zeilen an eine Anfrage ohne Anmeldung heraus, und die Lovable-Zahlen zeigen, wie die Ergebnisse eines Builders aussehen, sobald Unterlagen in den Schubladen liegen. Ein Schloss, das jeder Schlüssel öffnet, ist auch kein Schloss: Eine Policy mit using (true) lässt alle durch, während das Dashboard die Tabelle als geschützt anzeigt. RLS ist an und deine Tabelle trotzdem öffentlich erzählt die ganze Geschichte.

Wenn deine Daten stattdessen hinter Routen liegen, die dein eigener Servercode beantwortet, stellt sich dieselbe Frage für diese Routen: was ein offener API-Endpunkt bedeutet.

Was sich ändert, wenn du veröffentlichst oder selbst deployst

Der Schrank zieht aus dem Ausstellungsraum in dein Büro, und die Entscheidungen, die bisher die Domain von v0 getroffen hat, werden deine.

Veröffentlichen aus v0 legt ein Vercel-Projekt an und fragt laut v0s Deployment-Dokumentation drei Dinge ab: den Projektnamen, wer auf die veröffentlichte App zugreifen darf, und die Domain, entweder eine vercel.app-Adresse oder eine eigene. Nimm dir für die zweite Zeit. Welche Optionen du siehst, hängt von deinem Tarif ab, und wenn du die App auf dein Team beschränkst oder hinter ein Passwort legst, bis du sie geprüft hast, bleiben Fremde draußen, während du nachsiehst.

Drei Dinge gehen beim Veröffentlichen auf dich über:

• Die Header. Die Türen und Alarmanlagen des Büros stellst jetzt du ein.
• Die Umgebungsvariablen. Sie liegen in den Einstellungen deines Projekts, und in dieser Liste entscheidet sich, ob ein Schlüssel das Präfix NEXT_PUBLIC_ bekommt oder nicht.
• Die Prüfung deines Deployments, wenn du Vercel verlässt. Vercel beschreibt seine Sperre als etwas, das Deployments auf Vercel stoppt, also geht Code, den du herunterlädst und woanders hostest, ohne diese Prüfung raus.

So oder so hast du die Stichprobe verlassen, die wir gemessen haben. Eine v0-App auf eigener Domain mit einer Datenbank dahinter hat mehr gemeinsam mit den Bolt-Apps, die wir gemessen haben, als mit diesen 1.790 Vorschauen.

So prüfst du deine eigene v0-App

Fünf Dinge, und die ersten drei zählen erst, wenn du eine Datenbank verbunden oder veröffentlicht hast. Nimm ein privates Fenster, damit nicht deine eigene Anmeldung für einen Fremden antwortet.

1. Lies deine Umgebungsvariablen. In v0 findest du sie im Projektmenü unter Settings, Environment Variables. Alles, was mit NEXT_PUBLIC_ beginnt, steht im Code, den jeder Besucher lädt. Eine Projektadresse und ein veröffentlichbarer Schlüssel gehören dorthin. Ein Schlüssel, der dir Kosten verursacht, SUPABASE_SECRET_KEY und alles, was ein Passwort enthält, nie. Trug einer davon je das Präfix, rotiere ihn zuerst beim Anbieter, denn der alte Wert funktioniert weiter, bis du das tust.
2. Lies das Schloss an jeder Tabelle. Öffne in Supabase Authentication → Policies und geh die Liste durch. Eine Tabelle mit deaktivierter Row Level Security ist für jeden lesbar, der deine Projektadresse hat, und die steht in deiner Seite. Eine Policy, die allen alles erlaubt, zählt als deaktiviert.
3. Wähle beim Veröffentlichen, wer sie sehen darf. Nur dein Team oder ein Passwort, bis die ersten beiden erledigt sind.
4. Setze deine Header, sobald die Domain dir gehört. Zwei davon sind je eine Zeile.
5. Dann sieh von außen hin. Unser Scan führt alle neun Checks gegen die veröffentlichte Adresse aus, so wie ein Fremder sie sieht, dauert etwa 20 Sekunden und braucht kein Konto: App kostenlos scannen.

Ein Scan von außen sieht weder den Code, den v0 geschrieben hat, noch den Chat, in dem du ihn geschrieben hast, noch eine Tabelle, die deine Seiten nie erwähnen. v0s Checks sehen den Code von innen und sehen nicht, was ein Fremder unter der Adresse bekommt. Lass die von v0 laufen, während du baust, sieh nach dem Veröffentlichen von außen hin, und wenn die beiden je uneins sind, ob eine Tabelle lesbar ist, verlass dich auf die Antwort von außen, denn die bekommt ein Fremder. Die Version in einfacher Sprache für diese Plattform ist ist deine v0-App sicher.

Damit es nach dem Veröffentlichen so bleibt

Ein A für eine Vorschau beschreibt eine Vorschau. An dem Tag, an dem du eine Datenbank verbindest oder auf deiner eigenen Domain veröffentlichst, kann sich deine Note ändern, und nichts auf deinem Bildschirm sagt dir, dass sie es getan hat.

Reeve Monitor führt die neun Checks für dich erneut aus:

• alle neun Checks stündlich, für bis zu drei Apps
• ob die App läuft, alle 60 Sekunden
• eine Nachricht, wenn sich ein Ergebnis ändert, damit eine neue Tabelle oder ein neuer Schlüssel nicht wartet, bis du nachsiehst
• ein Monatsbericht über das, was er gesehen hat

Monitor kostet €12 im Monat zum Listenpreis, mit sieben freien Tagen, bevor abgerechnet wird. Die Preisseite liegt manchmal unter der Zahl hier und nie darüber.

Wenn deine v0-App ihre Daten in Supabase hält, bewahrt Reeve Care eine Kopie deiner Supabase-Datenbank auf.

• jede Nacht eine verschlüsselte Kopie, dort aufbewahrt, wo dein Projekt nicht hinkommt
• jede Kopie geprüft, bevor sie zählt: Wir zählen die Zeilen jeder Tabelle nach
• eine Wiederherstellung per Klick, wenn du sie brauchst
• auch deine hochgeladenen Dateien, sobald du einen Storage-Zugang verbindest
• alles, was Monitor macht

Care kostet €49 im Monat zum Listenpreis für eine App, mit denselben sieben freien Tagen.

Laut v0s Dokumentation kann es Tabellen auch löschen, nicht nur anlegen, und keiner der neun Checks oben würde die Zeilen darin zurückbringen. Der Tag, an dem ein KI-Agent eine Produktionsdatenbank gelöscht hat zeigt, wie das von innen aussieht.

Was du diese Woche tun solltest

Fang mit den Umgebungsvariablen an, denn sie entscheiden, was jeder Besucher lädt. Wenn du noch zwischen Buildern wählst, stellt welcher KI-App-Builder am sichersten ist alle fünf nebeneinander.