Sicherheit für deine v0-App

Typische Risiken bei v0

Client-seitiger Fetch mit dem Key im Klartext

Der Code, den v0 erzeugt, ruft APIs oft direkt aus der Komponente auf. Wenn dieser Aufruf einen Key mitschleppt, wandert er in den Browser und jeder liest ihn in den DevTools.

Aktionen, die die Session nie prüfen

v0 blendet einen Button aus, wenn du ihn nicht sehen sollst, validiert die Session aber nicht auf dem Server. Die Aktion bleibt eine öffentliche URL, die jeder direkt aufrufen kann.

Keine Header oder CSP von Haus aus

Da es UI-first-Code ist, kommt aus v0 etwas raus, das ohne Security-Header oder Content-Security-Policy ausgeliefert wird. Du musst sie überall dort konfigurieren, wo du deployst.

„v0-Sicherheit" sind zwei Dinge, die man auseinanderhalten sollte. Das erste ist das v0-Projekt: wer deine Chats sehen kann, wo Umgebungsvariablen leben, was Integrationen hinzufügen und wohin deployed wird. Das zweite ist der Code, den v0 erzeugt: sehr sauber gestaltete Next.js-Oberflächen, die sich per Design auf das Sichtbare konzentrieren und das Unsichtbare auf später verschieben, und das sind genau Authentifizierung, Validierung und Header. Dieser Guide deckt beides ab, mit einem Anweisungsblock für das Projekt, einem Review-Prompt vor dem Deploy und den Prüfungen von außen. Das Modell davon, was auf dem Server läuft und was den Browser erreicht, steht im Next.js-Guide.

Teil 1: Dein v0-Projekt absichern

Öffentliche und private Chats

Ein v0-Chat lässt sich per Link teilen oder in der Community veröffentlichen, und in beiden Fällen zeigt er den kompletten Code und den Prompt-Verlauf, einschließlich jedes Schlüssels, den du in die Unterhaltung eingefügt hast, und der Namen deiner Umgebungsvariablen. Prüf die Sichtbarkeit jedes Chats, bevor du ihn teilst, und geh davon aus, dass alles, was du in einem öffentlichen Chat geschrieben hast, schon jemand gelesen hat.

Umgebungsvariablen und Integrationen

v0 hat ein Panel für Umgebungsvariablen pro Projekt, das in der Vorschau genutzt und beim Deploy mit Vercel synchronisiert wird. Das ist der einzige Ort für Schlüssel: nie der Chat, nie eine Datei im Code. Integrationen (Supabase, Neon, Upstash, Blob und die übrigen aus dem Vercel-Marketplace) tragen ihre Variablen dort automatisch ein; die mit NEXT_PUBLIC_ erreichen den Browser, die übrigen nur den Server. Hat ein geheimer Schlüssel dieses Präfix, ist er offengelegt, obwohl du ihn ins Panel gesetzt hast.

Vorschau und Deployment

Die Vorschau in v0 führt deine App mit deinen echten Variablen aus. Das Deployment geht zu Vercel, mit allem, was das bedeutet: standardmäßig öffentliche Previews, Variablen pro Umgebung, Firewall und Deployment-Schutz. Der Vercel-Guide geht das durch; als Erstes aktivierst du Deployment Protection.

Wenn du eine Datenbank anbindest

Mit Supabase, Neon oder irgendeinem Postgres entstehen die Tabellen, die v0 anlegt, ohne Zugriffs-Policies und mit dem Schema, das sich das Modell ausgedacht hat. Bei Supabase hat der Supabase-Guide drei SQL-Abfragen, um das in einer Minute zu prüfen; bei anderen Datenbanken steuert dein Servercode den Zugriff, und es gelten die Regeln aus Teil 2.

Teil 2: Die Fehler, die v0 in deinen Code einbaut

Keine Authentifizierung. v0 baut das Dashboard, die Tabelle und die Buttons; der Login kommt „im nächsten Prompt" oder nie. Eine deployte App mit Dashboard und ohne Sitzung ist komplett öffentlich.
Beispieldaten, die bleiben. Fiktive Nutzer, Testschlüssel und ein admin / admin in einer Datendatei, die in Produktion landet.
fetch aus der Komponente mit dem Schlüssel darin. Der Aufruf der externen API steht in der Client-Komponente, mit dem Schlüssel sichtbar in den Browser-Tools.
Server Actions und Route Handlers ohne Sitzungsprüfung. Der Button wird versteckt, wenn du kein Admin bist, aber die Action bleibt ein Endpunkt, den jeder aufrufen kann.
Hübsche Formulare ohne Servervalidierung. Das Feld hat Regeln im Client; die Action nimmt, was kommt.
dangerouslySetInnerHTML für Rich Content. Perfekt für die Demo, XSS in Produktion, wenn ein Nutzer den Inhalt schreibt.
Remote-Bilder mit Platzhalter. remotePatterns mit hostname: '**', damit „jedes Bild funktioniert".
Keine Header, kein CSP. Die next.config kommt leer aus der Generierung.

Ein Anweisungsblock für das Projekt

Füg ihn in die Projektanweisungen in v0 ein oder, wenn du die nicht nutzt, an den Anfang deines ersten Prompts, damit er für alle Generierungen gilt:

Sicherheitsregeln dieses Projekts:
- Jede Dashboard-Seite und jede Action, die Daten liest oder schreibt, prüft die Sitzung auf dem Server. Gibt es kein Authentifizierungssystem, bau es vor jedem Dashboard.
- Aufrufe an Dienste mit Schlüssel gehören in Route Handlers oder Server Actions, nie in Client-Komponenten. Kein geheimer Schlüssel trägt das Präfix NEXT_PUBLIC_.
- Jede Server Action und jeder Route Handler validiert die Eingabe mit einem Schema, bevor Daten angefasst werden.
- Gib Client-Komponenten nur die nötigen Felder, nie das ganze Nutzerobjekt.
- Keine Beispieldaten mit Zugangsdaten; werden Testdaten gebraucht, markiere sie und sag es mir, damit ich sie vor dem Deploy entferne.
- Nutze dangerouslySetInnerHTML nicht mit Nutzerinhalt.
- images.remotePatterns listet konkrete Domains. next.config definiert Sicherheits-Header und aktiviert productionBrowserSourceMaps nicht.

Ein Review-Prompt vor dem Deploy

Prüfe die Sicherheit dieses Projekts und ändere noch nichts. Antworte mit einer Liste:
1. Seiten, Server Actions und Route Handlers, die Daten lesen oder schreiben, ohne die Sitzung zu prüfen.
2. Client-Komponenten, die externe Dienste mit einem Schlüssel aufrufen, und NEXT_PUBLIC_-Variablen mit geheimen Schlüsseln.
3. Beispieldaten, Zugangsdaten oder Testschlüssel im Code.
4. Actions ohne Eingabevalidierung und Verwendungen von dangerouslySetInnerHTML.
5. remotePatterns mit Platzhalter, fehlende Sicherheits-Header und aktiviertes productionBrowserSourceMaps.
Schlag für jeden Punkt die exakte Änderung vor und warte auf meine Bestätigung.

Prüf das Ergebnis von außen

curl -sI https://deinedomain.com | grep -iE "strict-transport|content-security|x-frame|x-content-type"
curl -s -o /dev/null -w "%{http_code}\n" https://deinedomain.com/dashboard
curl -s https://deinedomain.com | grep -oE '/_next/static/chunks/[^"]+\.js' | head -3

Erwartet: Header vorhanden und in der zweiten Zeile eine Weiterleitung (302 oder 307) zum Login; ein 200 heißt, das Dashboard ist öffentlich. Öffne die Chunks aus dem dritten Befehl und such nach sk_, Bearer und den Namen deiner Dienste. Scanaris führt diese Prüfungen und rund vierzig weitere in 30 Sekunden aus: Es erkennt, dass die App Next.js auf Vercel ist, sucht Geheimnisse in den Chunks, prüft Source Maps, Header, CSP, Cookies, CORS und offengelegte Dateien, kontrolliert deine Metadaten und gibt dir für jeden Fehler einen Fix-Prompt zum Einfügen in v0. Und es kann täglich neu scannen, weil eine Neugenerierung einen behobenen Fehler zurückbringen kann.

Häufige Fragen

Ist v0-Code produktionsreif?

Die Oberfläche ja; Sicherheit ist nicht inbegriffen. Bevor du etwas mit echten Daten deployst, braucht es Authentifizierung, Servervalidierung und Header, genau das, was Block und Prompt oben durchgehen.

Macht das Deployen aus v0 meine App privat?

Nein. Das Deployment ist öffentlich wie jedes andere auf Vercel, die Previews ebenso. Privat wird sie durch dein Sitzungssystem und Deployment Protection.

Was tue ich, wenn ich einen Schlüssel in den Chat eingefügt habe?

Rotiere ihn beim Ursprungsdienst, auch wenn du ihn löschst: Der Chat behält ihn, und war er öffentlich, hat ihn schon jeder gesehen. Trag ihn danach im Panel der Umgebungsvariablen ein und bitte v0, den Aufruf auf den Server zu verschieben.

Besteht deine v0-App diese Checks?

Scanne sie kostenlos und erhalte einen Fix-Prompt für jedes Problem, das wir finden.

Meine Website kostenlos scannen