Reeve Votre appli v0 est-elle sûre ?
v0 est-il sûr pour construire ? Les composants générés ne sont pas le risque. Le câblage autour l'est, et un nom de variable en décide presque tout.
Les logos sont la propriété de leurs détenteurs respectifs et servent uniquement à indiquer la compatibilité.
En bref
- Une appli v0 se publie en général sans crainte ; les composants générés ne sont pas le risque. Le câblage que vous ajoutez autour l'est.
- Toute variable nommée NEXT_PUBLIC_… est compilée dans le JavaScript que vos visiteurs téléchargent. C'est correct pour une clé publiable et faux pour une clé secrète.
- v0 ne définit pas vos règles de base de données. Sur Supabase, les tables créées en exécutant du SQL démarrent sans Row Level Security.
v0 vous donne des composants : une interface qui marche, générée et déposée dans votre projet. Ce qu'il ne vous donne pas, c'est le câblage derrière : les variables d'environnement, la base de données, les règles sur qui peut lire quoi. C'est dans cet écart qu'un projet v0 déraille en général, et il déraille en silence.
Voici ce que guide après guide raconte de travers : le code généré n'est pas le risque. Le risque est une convention de nommage dans votre fichier d'environnement, et un réglage de base de données qui n'a rien à voir avec v0.
Quelle moitié d'un projet v0 est publique
La moitié interface, entièrement.
Voyez cela comme une boutique. Les composants que v0 écrit sont la devanture : chaque page, chaque formulaire, chaque bouton, et toute la devanture est remise à chaque visiteur qui charge votre site. On ne peut pas contourner cela ; un navigateur ne peut pas rendre une page qu'on ne lui a pas envoyée. Derrière se trouve la réserve, votre base de données, un bâtiment séparé avec sa propre serrure.
Ce qui rend un projet v0 particulier, c'est que vous assemblez les deux vous-même. Les composants arrivent sans rien savoir de vos clés ni de vos tables, donc toute décision sur ce qui passe de la réserve à la devanture est une décision que vous prenez dans votre propre projet, le plus souvent dans un seul fichier plein de variables d'environnement.
Ce que NEXT_PUBLIC_ veut vraiment dire
Cela veut dire « mets ceci dans le navigateur ».
Next.js, ce pour quoi v0 génère du code, décide de ce que reçoivent vos visiteurs
en lisant le nom de la variable. Tout ce qui s'appelle
NEXT_PUBLIC_QUELQUE_CHOSE est compilé dans le JavaScript que votre site sert.
Tout ce qui n'a pas ce préfixe reste sur le serveur. La même règle existe sous
d'autres noms dans d'autres outils (Vite utilise un préfixe VITE_ et indique
clairement que ces valeurs sont intégrées à votre code source au moment du
build), mais l'effet est identique : le préfixe publie la valeur.
C'est exactement ce qu'il faut pour une URL de projet ou une clé publiable. C'est exactement l'inverse pour une clé secrète.
Le piège a une forme reconnaissable. Quelque chose dans l'interface ne peut pas
lire une valeur, alors on ajoute le préfixe pour faire disparaître l'erreur, et
elle disparaît : l'appli se met à marcher. Si la valeur était une clé Supabase
sb_publishable_…, ou l'ancienne clé anon, rien de grave. Si c'était
sb_secret_… ou service_role, l'erreur était le système qui vous disait que ce
code a sa place sur un serveur, et le renommage a publié une clé qui ignore
toutes les règles que vous avez posées.
Distinguer les deux prend une
minute et vaut le coup une fois pour chaque clé du fichier.
Ce qui décide si des inconnus peuvent lire vos données
Vos règles de base de données, pas vos composants.
Si vos données sont dans Supabase, le réglage s'appelle Row Level Security : un interrupteur par table qui décide ligne par ligne qui peut lire quoi. Désactivé, votre clé publiable renvoie la table entière à quiconque la demande. Activé et accompagné d'une politique, elle ne renvoie que ce que la politique autorise.
Supabase l'active par défaut pour les tables créées dans le Table Editor du tableau de bord, et pas pour celles créées en exécutant du SQL. Les tables que vous avez fait naître en cliquant sont donc en général protégées, et toute table créée par un fichier de migration ne l'est peut-être pas. Après coup, les deux se ressemblent, et les deux marchent.
Il existe une seconde version de ce piège, qui attrape ceux qui ont tout bien fait : une table peut avoir Row Level Security activé et rester ouverte à tous, à cause de la politique posée dessus. Activé et protégé sont deux états différents.
Comment vérifier votre projet v0 en une dizaine de minutes
Lisez votre fichier d'environnement ligne par ligne. Toute variable avec le
préfixe NEXT_PUBLIC_ est publiée. Demandez-vous pour chacune : serais-je à
l'aise en imprimant ceci sur la page d'accueil ? Si non, elle n'a pas sa place
avec ce préfixe.
Renouvelez tout ce qui n'aurait jamais dû s'y trouver. Dans le tableau de bord de votre fournisseur, générez une nouvelle clé et révoquez l'ancienne. Retirer la ligne de votre code ne ferme pas la porte, car l'ancienne valeur est toujours dans votre historique de versions et dans les copies en cache du site.
Vérifiez les règles de vos tables. Dans Supabase, Authentication → Policies liste chaque table et l'état de Row Level Security. Tout ce qui est désactivé est lisible par quiconque connaît l'adresse de votre projet.
Puis regardez depuis l'extérieur. Les étapes ci-dessus vous disent ce qui est configuré ; elles ne vous disent pas ce qui est réellement atteignable. Notre scan gratuit lit votre site en ligne comme le ferait un visiteur et vous donne une note en une vingtaine de secondes, sans compte : scanner votre appli.
Que faire
NEXT_PUBLIC_n'est pas une formalité. Il compile la valeur dans les fichiers que chaque visiteur télécharge.- Ajouter le préfixe pour faire taire une erreur est le moment de s'arrêter et de vérifier ce que la valeur contient vraiment.
- Une clé publiable a sa place dans le navigateur.
sb_secret_…etservice_rolejamais. - v0 ne définit pas vos règles de base de données. Sur Supabase, les tables créées en exécutant du SQL démarrent sans Row Level Security.
- Une table avec Row Level Security activé peut rester ouverte à tous. C'est la politique qui décide.
Ouvrez votre fichier d'environnement et lisez les lignes NEXT_PUBLIC_ à voix
haute. Si l'une d'elles contient quelque chose que vous n'imprimeriez pas sur
votre page d'accueil, renouvelez-la maintenant, puis la
checklist sécurité en 10 minutes couvre ce qu'il vaut encore la
peine de désactiver dans un projet fraîchement lancé.
Ce qui peut réellement mal tourner avec une appli v0
Rien de tout cela n'est de votre faute : ce sont les effets secondaires normaux d'une génération rapide de code. Voici ce qui vaut la peine d'être vérifié :
Une clé secrète dans un composant client (le piège NEXT_PUBLIC_)
v0 construit avec Next.js, qui a une règle qui fait trébucher : tout ce qui est nommé NEXT_PUBLIC_, et toute clé écrite directement dans un composant client, est envoyé au navigateur, où n'importe qui peut le lire. Il est facile de coller une clé d'API dans un composant généré sans réaliser qu'elle est désormais publique. Certaines clés sont censées être publiques ; Reeve les distingue de celles qui ne le sont pas, donc pas de fausses alertes.
Votre base de données laissée ouverte (RLS de Supabase désactivé)
Si votre appli v0 stocke des données (souvent dans Supabase), il existe un interrupteur appelé Row Level Security (RLS) qui décide qui peut lire ou modifier chaque ligne. S'il est désactivé, vos tables peuvent être ouvertes à quiconque trouve l'adresse. C'est le problème sérieux le plus fréquent dans les applis générées, et il reste invisible tant que vous ne regardez pas.
Source maps publiées
Une « source map » révèle le code d'origine de votre appli à quiconque ouvre les outils du navigateur. C'est utile pendant le développement, mais si elle part en production, elle donne aux inconnus une copie lisible du fonctionnement de votre appli, et rend chaque autre faille plus facile à trouver. Reeve vérifie si les vôtres sont exposées.
Routes d'API ouvertes
Les applis Next.js incluent souvent des routes d'API : de petits points d'accès qui font des choses comme lire ou écrire des données. Si l'une a été générée sans vérification d'authentification, elle peut répondre à quiconque l'appelle. Reeve sonde si vos points d'accès répondent aux inconnus, sans jamais s'en servir pour modifier quoi que ce soit.
Un fichier .env ou de configuration exposé
Le fichier .env contient les clés d'un projet. Il est parfois publié par erreur avec l'appli déployée, et s'il est accessible, c'est un raccourci vers tout ce qui est sensible. Reeve vérifie si le vôtre est discrètement accessible.
En-têtes de sécurité manquants & partage ouvert (CORS)
De petits réglages qui indiquent aux navigateurs comment protéger les visiteurs, et si n'importe quel site est autorisé à appeler les données de votre appli. Mineurs isolément ; ensemble, ils élargissent la faille. Reeve signale ce qui manque.
Ce que Reeve est, et ce qu'il n'est pas
Reeve est une vérification gratuite, en lecture seule, depuis l'extérieur, comme un inspecteur qui essaie les portes sans entrer. C'est rapide et ça repère les erreurs courantes à fort impact. Ce n'est pas un audit de sécurité complet, et une note propre n'est pas une garantie. Elle signifie que les portes évidentes sont fermées.
v0 et Vercel élèvent sans cesse la qualité de ce qui est généré et déployé, et si vous utilisez Supabase, son propre conseiller signale les problèmes de base de données dans le tableau de bord. Les deux aident. Ce que Reeve ajoute : vous travaillez dans v0, vous ne lisez pas le code généré ligne par ligne, et ces outils parlent le langage des développeurs. Reeve regarde toute l'appli déployée depuis l'extérieur et vous dit ce qu'il trouve en mots simples. Et si vous préférez ne pas y penser, nous pouvons la surveiller pour vous.
Vous voulez que ce soit géré, pas seulement vérifié ?
Reeve Care continue de surveiller votre appli, sauvegarde vos données et vous aide à réparer les choses quand elles cassent, pour que vous puissiez continuer à créer au lieu de vous inquiéter.
En savoir plus sur Reeve CareFAQ
Le code de v0 est-il prêt pour la production et sûr ?
v0 produit du code propre et moderne, mais « a l'air prêt pour la production » n'est pas la même chose que « vérifié ». La sécurité dépend de la façon dont l'appli est câblée : où vivent les clés, si les règles de votre base de données sont activées, si les points d'accès sont protégés. Reeve vérifie les parties exposées gratuitement en environ 20 secondes.
Une appli v0 peut-elle exposer mes clés d'API ?
Oui, si une clé se retrouve dans un composant client ou un réglage NEXT_PUBLIC_, Next.js les envoie au navigateur. Toutes les clés ne posent pas problème : certaines sont censées être publiques. Reeve trouve les clés dans votre code chargé et vous dit lesquelles sont sûres et lesquelles doivent être déplacées vers le serveur.
Les routes d'API de v0 sont-elles sûres ?
Elles peuvent l'être, mais un point d'accès généré part parfois sans vérification d'authentification, ce qui signifie que quiconque le trouve peut l'appeler. Reeve teste si vos points d'accès répondent aux inconnus ; il vérifie seulement que la porte s'ouvre, il ne la franchit jamais.
Analyser mon appli v0 va-t-il casser quelque chose ?
Non. Reeve regarde seulement ce qui est déjà public depuis l'extérieur. Il ne se connecte jamais, ne modifie jamais rien et ne télécharge jamais de données. En lecture seule, comme vérifier si une porte est verrouillée sans entrer.
À quoi sert vraiment le préfixe NEXT_PUBLIC_ ?
Il dit à Next.js de compiler cette valeur dans le JavaScript envoyé au navigateur. La valeur cesse d'être un réglage côté serveur et devient une partie de vos fichiers publiés, lisible par n'importe quel visiteur. C'est correct pour une clé publiable et faux pour une clé secrète, et le préfixe est la seule chose qui en décide.
J'ai renommé une variable pour ajouter NEXT_PUBLIC_ parce que l'appli ne pouvait pas la lire. Était-ce une erreur ?
Cela dépend entièrement de ce que contient la variable. Si c'était une clé publiable ou une URL de projet, le renommage était la bonne correction. Si c'était une clé secrète, l'appli ne pouvait pas la lire parce qu'elle n'a jamais été faite pour tourner dans le navigateur, et le renommage l'a publiée. Renouvelez cette clé, puis déplacez le code qui en avait besoin vers une route serveur.
v0 configure-t-il mes règles de base de données à ma place ?
Pas tout seul. v0 génère du code d'interface ; la base de données et ses règles sont à vous de les mettre en place là où vous les hébergez. Si vous êtes sur Supabase, Row Level Security est activé par défaut uniquement pour les tables créées dans le Table Editor du tableau de bord, et désactivé pour celles créées en exécutant du SQL.