Sicurezza per la tua app v0

"Sicurezza in v0" sono due cose che conviene tenere separate. La prima è il progetto v0: chi può vedere le tue chat, dove vivono le variabili d'ambiente, cosa aggiungono le integrazioni e dove viene fatto il deploy. La seconda è il codice che v0 genera: interfacce Next.js molto rifinite che, per design, si concentrano su ciò che si vede e rimandano ciò che non si vede, cioè proprio autenticazione, validazione e header. Questa guida copre entrambe, con un blocco di istruzioni per il progetto, un prompt di revisione prima del deploy e le verifiche dall'esterno. Il modello di cosa gira sul server e cosa arriva al browser è nella guida Next.js.

Parte 1: proteggere il tuo progetto v0

Chat pubbliche e private

Una chat di v0 può essere condivisa via link o pubblicata nella community, e in entrambi i casi mostra il codice completo e la cronologia dei prompt, inclusa qualsiasi chiave incollata nella conversazione e i nomi delle tue variabili d'ambiente. Controlla la visibilità di ogni chat prima di condividerla, e dai per scontato che tutto ciò che hai scritto in una chat pubblica l'abbia già letto qualcuno.

Variabili d'ambiente e integrazioni

v0 ha un pannello di variabili d'ambiente per progetto che viene usato nell'anteprima e sincronizzato con Vercel al deploy. È l'unico posto per le chiavi: mai la chat, mai un file del codice. Le integrazioni (Supabase, Neon, Upstash, Blob e le altre del marketplace Vercel) aggiungono lì le loro variabili automaticamente; quelle che iniziano con NEXT_PUBLIC_ arrivano al browser e le altre solo al server. Se una chiave segreta ha quel prefisso, è esposta anche se l'hai messa nel pannello.

Anteprima e deploy

L'anteprima dentro v0 esegue la tua app con le tue variabili reali. Il deploy va su Vercel, con tutto ciò che implica: anteprime pubbliche di default, variabili per ambiente, firewall e protezione dei deploy. La guida Vercel lo ripassa; la prima cosa da attivare è Deployment Protection.

Se colleghi un database

Con Supabase, Neon o qualsiasi Postgres, le tabelle che v0 crea nascono senza policy di accesso e con lo schema che il modello ha immaginato. Se è Supabase, la guida Supabase ha tre query SQL per fare l'audit in un minuto; con altri database, l'accesso lo controlla il tuo codice server e valgono le regole della parte 2.

Parte 2: i difetti che v0 mette nel tuo codice

• Senza autenticazione. v0 costruisce la dashboard, la tabella e i pulsanti; il login arriva "al prossimo prompt" o mai. Un'app pubblicata con una dashboard senza sessione è interamente pubblica.
• Dati di esempio che restano. Utenti fittizi, chiavi di prova e un admin / admin in un file di dati che finisce in produzione.
• fetch dal componente con la chiave dentro. La chiamata all'API esterna sta nel componente client, con la chiave in bella vista negli strumenti del browser.
• Server Actions e Route Handlers senza controllo della sessione. Il pulsante si nasconde se non sei amministratore, ma l'azione resta un endpoint che chiunque può invocare.
• Form belli senza validazione server. Il campo ha regole nel client; l'azione accetta quello che arriva.
• dangerouslySetInnerHTML per contenuto ricco. Perfetto per la demo, XSS in produzione se il contenuto lo scrive un utente.
• Immagini remote con wildcard. remotePatterns con hostname: '**' perché "qualsiasi immagine funzioni".
• Senza header né CSP. Il next.config esce vuoto dalla generazione.

Un blocco di istruzioni per il progetto

Incollalo nelle istruzioni del progetto in v0 o, se non le usi, all'inizio del tuo primo prompt, perché valga per tutte le generazioni:

Regole di sicurezza di questo progetto:
- Ogni pagina di dashboard e ogni azione che legge o scrive dati controlla la sessione sul server. Se non c'è un sistema di autenticazione, crealo prima di qualsiasi dashboard.
- Le chiamate a servizi con chiave vanno in Route Handlers o Server Actions, mai in componenti client. Nessuna chiave segreta ha il prefisso NEXT_PUBLIC_.
- Ogni Server Action e ogni Route Handler valida l'input con uno schema prima di toccare i dati.
- Passa ai componenti client solo i campi necessari, mai l'oggetto utente intero.
- Niente dati di esempio con credenziali; se servono dati di prova, segnalali e avvisami per toglierli prima del deploy.
- Non usare dangerouslySetInnerHTML con contenuto utente.
- images.remotePatterns elenca domini precisi. next.config definisce gli header di sicurezza e non attiva productionBrowserSourceMaps.

Un prompt di revisione prima del deploy

Rivedi la sicurezza di questo progetto e non cambiare ancora nulla. Rispondi con una lista:
1. Pagine, Server Actions e Route Handlers che leggono o scrivono dati senza controllare la sessione.
2. Componenti client che chiamano servizi esterni con una chiave, e variabili NEXT_PUBLIC_ che contengono chiavi segrete.
3. Dati di esempio, credenziali o chiavi di prova nel codice.
4. Azioni senza validazione dell'input e usi di dangerouslySetInnerHTML.
5. remotePatterns con wildcard, header di sicurezza assenti e productionBrowserSourceMaps attivo.
Per ogni punto, proponi la modifica esatta e aspetta la mia conferma.

Verifica il risultato dall'esterno

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

L'atteso: header presenti e un reindirizzamento (302 o 307) al login nella seconda riga; un 200 significa che la dashboard è pubblica. Apri i chunk del terzo comando e cerca sk_, Bearer e i nomi dei tuoi servizi. Scanaris fa queste verifiche e una quarantina di altre in 30 secondi: rileva che l'app è Next.js su Vercel, cerca segreti nei chunk, controlla source map, header, CSP, cookie, CORS e file esposti, verifica i tuoi metadati e ti dà un fix prompt per ogni errore da incollare in v0. E può riscansionare ogni giorno, perché una rigenerazione può riportare un difetto già sistemato.

Domande frequenti

Il codice di v0 è pronto per la produzione?

L'interfaccia sì; la sicurezza non è inclusa. Prima di pubblicare qualcosa con dati reali servono autenticazione, validazione server e header, che è ciò che ripassano il blocco e il prompt qui sopra.

Fare il deploy da v0 rende privata la mia app?

No. Il deploy è pubblico come qualsiasi altro su Vercel, e anche le anteprime. La privacy la danno il tuo sistema di sessione e Deployment Protection.

Cosa faccio se ho incollato una chiave nella chat?

Ruotala nel servizio di origine anche se la cancelli: la chat la conserva e, se era pubblica, l'ha già vista chiunque. Aggiungila poi nel pannello delle variabili d'ambiente e chiedi a v0 di spostare la chiamata sul server.