Sécurité pour ton appli v0

« Sécurité v0 », ce sont deux choses qu'il vaut mieux séparer. La première, c'est le projet v0 : qui peut voir tes chats, où vivent les variables d'environnement, ce qu'ajoutent les intégrations et où il est déployé. La seconde, c'est le code que v0 génère : des interfaces Next.js très soignées qui, par conception, se concentrent sur ce qui se voit et laissent pour plus tard ce qui ne se voit pas, c'est-à-dire justement l'authentification, la validation et les en-têtes. Ce guide couvre les deux, avec un bloc d'instructions pour le projet, un prompt de revue avant de déployer et les vérifications de l'extérieur. Le modèle de ce qui tourne sur le serveur et de ce qui atteint le navigateur est dans le guide Next.js.

Partie 1 : protéger ton projet v0

Chats publics et privés

Un chat v0 peut être partagé par lien ou publié dans la communauté, et dans les deux cas il montre le code complet et l'historique des prompts, y compris toute clé que tu as collée dans la conversation et les noms de tes variables d'environnement. Vérifie la visibilité de chaque chat avant de le partager, et pars du principe que tout ce que tu as écrit dans un chat public a déjà été lu par quelqu'un.

Variables d'environnement et intégrations

v0 a un panneau de variables d'environnement par projet, utilisé dans la prévisualisation et synchronisé avec Vercel au déploiement. C'est le seul endroit pour les clés : jamais le chat, jamais un fichier du code. Les intégrations (Supabase, Neon, Upstash, Blob et les autres de la marketplace Vercel) y ajoutent leurs variables automatiquement ; celles qui commencent par NEXT_PUBLIC_ atteignent le navigateur et les autres seulement le serveur. Si une clé secrète porte ce préfixe, elle est exposée même si tu l'as mise dans le panneau.

Prévisualisation et déploiement

La prévisualisation dans v0 exécute ton appli avec tes vraies variables. Le déploiement va sur Vercel, avec tout ce que ça implique : previews publiques par défaut, variables par environnement, pare-feu et protection des déploiements. Le guide Vercel passe tout ça en revue ; la première chose à activer, c'est Deployment Protection.

Si tu connectes une base de données

Avec Supabase, Neon ou n'importe quel Postgres, les tables que v0 crée naissent sans policies d'accès et avec le schéma que le modèle a imaginé. Si c'est Supabase, le guide Supabase contient trois requêtes SQL pour l'auditer en une minute ; avec d'autres bases, l'accès est contrôlé par ton code serveur et les règles de la partie 2 s'appliquent.

Partie 2 : les failles que v0 met dans ton code

• Pas d'authentification. v0 construit le tableau de bord, la table et les boutons ; le login arrive « au prompt suivant » ou jamais. Une appli déployée avec un dashboard sans session est entièrement publique.
• Des données d'exemple qui restent. Des utilisateurs fictifs, des clés de test et un admin / admin dans un fichier de données qui finit en production.
• Un fetch depuis le composant avec la clé dedans. L'appel à l'API externe est dans le composant client, avec la clé en clair dans les outils du navigateur.
• Des Server Actions et des Route Handlers qui ne vérifient pas la session. Le bouton est caché si tu n'es pas admin, mais l'action reste un endpoint que n'importe qui peut invoquer.
• De beaux formulaires sans validation serveur. Le champ a des règles côté client ; l'action accepte ce qui arrive.
• dangerouslySetInnerHTML pour du contenu enrichi. Parfait pour la démo, XSS en production si c'est un utilisateur qui écrit le contenu.
• Des images distantes avec joker. remotePatterns avec hostname: '**' pour que « n'importe quelle image marche ».
• Ni en-têtes ni CSP. Le next.config sort vide de la génération.

Un bloc d'instructions pour le projet

Colle-le dans les instructions du projet dans v0 ou, si tu ne les utilises pas, au début de ton premier prompt, pour qu'il vaille pour toutes les générations :

Règles de sécurité de ce projet :
- Toute page de tableau de bord et toute action qui lit ou écrit des données vérifie la session sur le serveur. S'il n'y a pas de système d'authentification, construis-le avant tout tableau de bord.
- Les appels à des services avec clé vont dans des Route Handlers ou des Server Actions, jamais dans des composants client. Aucune clé secrète ne porte le préfixe NEXT_PUBLIC_.
- Chaque Server Action et chaque Route Handler valide l'entrée avec un schéma avant de toucher aux données.
- Ne passe aux composants client que les champs nécessaires, jamais l'objet utilisateur entier.
- Pas de données d'exemple avec des identifiants ; s'il faut des données de test, marque-les et préviens-moi pour les retirer avant de déployer.
- N'utilise pas dangerouslySetInnerHTML avec du contenu utilisateur.
- images.remotePatterns liste des domaines précis. next.config définit les en-têtes de sécurité et n'active pas productionBrowserSourceMaps.

Un prompt de revue avant de déployer

Passe en revue la sécurité de ce projet et ne change rien pour l'instant. Réponds avec une liste :
1. Pages, Server Actions et Route Handlers qui lisent ou écrivent des données sans vérifier la session.
2. Composants client qui appellent des services externes avec une clé, et variables NEXT_PUBLIC_ contenant des clés secrètes.
3. Données d'exemple, identifiants ou clés de test dans le code.
4. Actions sans validation d'entrée et usages de dangerouslySetInnerHTML.
5. remotePatterns avec joker, en-têtes de sécurité absents et productionBrowserSourceMaps activé.
Pour chaque point, propose le changement exact et attends ma confirmation.

Vérifie le résultat de l'extérieur

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

Attendu : en-têtes présents et une redirection (302 ou 307) vers le login sur la deuxième ligne ; un 200 signifie que le tableau de bord est public. Ouvre les chunks de la troisième commande et cherche sk_, Bearer et les noms de tes services. Scanaris fait ces vérifications et une quarantaine d'autres en 30 secondes : il détecte que l'appli est en Next.js déployée sur Vercel, cherche des secrets dans les chunks, vérifie source maps, en-têtes, CSP, cookies, CORS et fichiers exposés, contrôle tes métadonnées et te donne un fix prompt pour chaque échec à coller dans v0. Et il peut rescanner chaque jour, parce qu'une régénération peut ramener une faille corrigée.

Questions fréquentes

Le code de v0 est-il prêt pour la production ?

L'interface, oui ; la sécurité n'est pas incluse. Avant de déployer quoi que ce soit avec de vraies données, il faut une authentification, une validation serveur et des en-têtes, ce que passent en revue le bloc et le prompt ci-dessus.

Déployer depuis v0 rend-il mon appli privée ?

Non. Le déploiement est public comme n'importe quel autre sur Vercel, et les previews aussi. La confidentialité vient de ton système de session et de Deployment Protection.

Que faire si j'ai collé une clé dans le chat ?

Fais-la tourner chez le service d'origine même si tu l'effaces : le chat la conserve et, s'il était public, n'importe qui l'a déjà vue. Ajoute-la ensuite dans le panneau des variables d'environnement et demande à v0 de déplacer l'appel côté serveur.