Beveiliging voor je v0-app

"v0-beveiliging" zijn twee dingen die je beter uit elkaar houdt. Het eerste is het v0-project: wie je chats kan zien, waar omgevingsvariabelen leven, wat integraties toevoegen en waar het gedeployed wordt. Het tweede is de code die v0 genereert: zeer verzorgde Next.js-interfaces die zich bewust richten op wat zichtbaar is en wat onzichtbaar is voor later laten, en dat is precies authenticatie, validatie en headers. Deze gids behandelt beide, met een instructieblok voor het project, een reviewprompt vóór het deployen en de controles van buitenaf. Het model van wat op de server draait en wat de browser bereikt, staat in de Next.js-gids.

Deel 1: je v0-project beveiligen

Publieke en privéchats

Een v0-chat kan via een link gedeeld of in de community gepubliceerd worden, en in beide gevallen toont hij de volledige code en de promptgeschiedenis, inclusief elke sleutel die je in het gesprek plakte en de namen van je omgevingsvariabelen. Controleer de zichtbaarheid van elke chat voordat je hem deelt, en ga ervan uit dat alles wat je in een publieke chat schreef al door iemand gelezen is.

Omgevingsvariabelen en integraties

v0 heeft per project een paneel met omgevingsvariabelen dat in de preview wordt gebruikt en bij het deployen met Vercel wordt gesynchroniseerd. Dat is de enige plek voor sleutels: nooit de chat, nooit een bestand in de code. Integraties (Supabase, Neon, Upstash, Blob en de rest van de Vercel-marketplace) voegen hun variabelen daar automatisch toe; die met NEXT_PUBLIC_ bereiken de browser, de rest alleen de server. Heeft een geheime sleutel dat voorvoegsel, dan ligt hij bloot, ook al zette je hem in het paneel.

Preview en deployment

De preview in v0 draait je app met je echte variabelen. De deployment gaat naar Vercel, met alles wat dat inhoudt: standaard publieke previews, variabelen per omgeving, firewall en deploymentbescherming. De Vercel-gids loopt het door; het eerste om in te schakelen is Deployment Protection.

Als je een database koppelt

Met Supabase, Neon of welke Postgres dan ook worden de tabellen die v0 aanmaakt geboren zonder toegangspolicies en met het schema dat het model bedacht. Is het Supabase, dan heeft de Supabase-gids drie SQL-query's om het in een minuut door te lichten; bij andere databases regelt je servercode de toegang en gelden de regels uit deel 2.

Deel 2: de fouten die v0 in je code stopt

• Geen authenticatie. v0 bouwt het dashboard, de tabel en de knoppen; de login komt "in de volgende prompt" of nooit. Een gedeployde app met een dashboard zonder sessie is volledig publiek.
• Voorbeelddata die blijft. Fictieve gebruikers, testsleutels en een admin / admin in een databestand dat in productie belandt.
• fetch vanuit de component met de sleutel erin. De aanroep naar de externe API staat in de clientcomponent, met de sleutel in het zicht in de browsertools.
• Server Actions en Route Handlers zonder sessiecontrole. De knop wordt verborgen als je geen admin bent, maar de actie blijft een endpoint dat iedereen kan aanroepen.
• Mooie formulieren zonder servervalidatie. Het veld heeft regels aan de clientkant; de actie accepteert wat er binnenkomt.
• dangerouslySetInnerHTML voor rijke inhoud. Perfect voor de demo, XSS in productie als een gebruiker de inhoud schrijft.
• Externe afbeeldingen met wildcard. remotePatterns met hostname: '**' zodat "elke afbeelding werkt".
• Geen headers, geen CSP. De next.config komt leeg uit de generatie.

Een instructieblok voor het project

Plak het in de projectinstructies in v0 of, als je die niet gebruikt, aan het begin van je eerste prompt, zodat het voor alle generaties geldt:

Beveiligingsregels van dit project:
- Elke dashboardpagina en elke actie die data leest of schrijft, controleert de sessie op de server. Is er geen authenticatiesysteem, bouw dat dan vóór enig dashboard.
- Aanroepen naar diensten met een sleutel gaan in Route Handlers of Server Actions, nooit in clientcomponenten. Geen enkele geheime sleutel draagt het voorvoegsel NEXT_PUBLIC_.
- Elke Server Action en elke Route Handler valideert de invoer met een schema voordat data wordt aangeraakt.
- Geef clientcomponenten alleen de velden die ze nodig hebben, nooit het hele gebruikersobject.
- Geen voorbeelddata met inloggegevens; zijn testdata nodig, markeer ze dan en zeg het me, zodat ik ze vóór het deployen verwijder.
- Gebruik geen dangerouslySetInnerHTML met gebruikersinhoud.
- images.remotePatterns somt specifieke domeinen op. next.config definieert beveiligingsheaders en schakelt productionBrowserSourceMaps niet in.

Een reviewprompt vóór het deployen

Beoordeel de beveiliging van dit project en verander nog niets. Antwoord met een lijst:
1. Pagina's, Server Actions en Route Handlers die data lezen of schrijven zonder de sessie te controleren.
2. Clientcomponenten die externe diensten met een sleutel aanroepen, en NEXT_PUBLIC_-variabelen die geheime sleutels bevatten.
3. Voorbeelddata, inloggegevens of testsleutels in de code.
4. Acties zonder invoervalidatie en gebruik van dangerouslySetInnerHTML.
5. remotePatterns met wildcard, ontbrekende beveiligingsheaders en ingeschakelde productionBrowserSourceMaps.
Stel voor elk punt de exacte wijziging voor en wacht op mijn bevestiging.

Controleer het resultaat van buitenaf

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

Verwacht: headers aanwezig en op de tweede regel een redirect (302 of 307) naar de login; een 200 betekent dat het dashboard publiek is. Open de chunks van het derde commando en zoek naar sk_, Bearer en de namen van je diensten. Scanaris voert deze controles en zo'n veertig andere uit in 30 seconden: het detecteert dat de app Next.js op Vercel is, zoekt geheimen in de chunks, controleert source maps, headers, CSP, cookies, CORS en blootgestelde bestanden, beoordeelt je metadata en geeft je voor elke fout een fix prompt om in v0 te plakken. En het kan elke dag opnieuw scannen, want een hergeneratie kan een opgeloste fout terugbrengen.

Veelgestelde vragen

Is v0-code klaar voor productie?

De interface wel; beveiliging zit er niet bij. Voordat je iets met echte data deployt, heeft het authenticatie, servervalidatie en headers nodig, precies wat het blok en de prompt hierboven doorlopen.

Maakt deployen vanuit v0 mijn app privé?

Nee. De deployment is publiek zoals elke andere op Vercel, en de previews ook. Privacy komt van je sessiesysteem en Deployment Protection.

Wat doe ik als ik een sleutel in de chat heb geplakt?

Roteer hem bij de brondienst, ook als je hem verwijdert: de chat bewaart hem en, als hij publiek was, heeft iedereen hem al gezien. Voeg hem daarna toe in het paneel met omgevingsvariabelen en vraag v0 de aanroep naar de server te verplaatsen.