Aller au contenu

Bases de la sécurité

Sécurité de v0 : les 1 790 applications scannées ont toutes eu A

La sécurité de v0 mesurée sur 1 790 applications en ligne : toutes ont eu A. Seules 17 citaient une base de données, et c’est surtout cela que ce A mesure.

Vlad Tkachenko13 min de lecture
Un classeur à tiroirs portant le logo v0, un tiroir vide ouvert, à côté d’un classeur aux tiroirs tous verrouillés.

En bref

  • Côté sécurité, v0 est sorti plus propre que tous les autres builders que nous avons mesurés : les 1 790 applications v0 en ligne que nous avons scannées ont eu A, et la seule trouvaille qu’elles partageaient est un réglage d’en-têtes sur le domaine depuis lequel v0 les sert.
  • Cela dit surtout ce que sont ces applications. Seules 17 des 1 790 citaient une base de données, et aucune de ces 17 n’a donné à notre vérification de base de données une réponse qu’elle pouvait juger.
  • Connectez Supabase, ou publiez sur votre propre domaine, et les vérifications revenues vides commencent à avoir quelque chose à vérifier.

Vous avez décrit une application à v0, vous l’avez regardé la construire, et il vous a rendu un lien qui se termine par vusercontent.net. Elle fonctionne, elle a l’air finie, et vous l’avez peut-être déjà envoyée à quelqu’un. Avant que de vrais clients y tapent leurs coordonnées, vous avez cherché la sécurité de v0, et une partie de ce qui est remonté était une histoire d’attaquants qui utilisaient v0 pour construire de fausses pages de connexion.

Cette histoire parle de ce que d’autres font avec l’outil. Cet article parle de l’application que vous avez faite avec, et pour cela nous avons une mesure. Du 12 au 14 août 2026, nous avons lancé les neuf mêmes vérifications externes que n’importe qui peut lancer gratuitement sur notre page d’accueil sur 30 998 applications en ligne, et 1 790 d’entre elles étaient des applications v0. Les 1 790 ont toutes eu A.

Voici ce qu’un classement comprend de travers : ce A en dit plus sur ce qu’il y avait à vérifier que sur v0. Lu comme un classement, il fait de v0 le builder le plus sûr que nous ayons mesuré. Lu avec ses dénominateurs, il décrit des frontends sans rien derrière, et il cesse de décrire le vôtre le jour où vous connectez une base de données.

v0 est-il sûr ?

Sur tout ce que nous avons pu mesurer de v0 lui-même, oui. Sa seule trouvaille appartient au domaine depuis lequel v0 sert votre application, et rien d’autre n’est apparu sur aucune des 1 790, dans aucune des neuf vérifications. Ce que cela ne peut pas vous dire, c’est comment votre application se comporte une fois qu’elle contient des données, parce que presque aucune de celles-ci n’en contenait.

Imaginez un aperçu v0 comme un classeur à tiroirs dans une salle d’exposition. Les tiroirs coulissent, les étiquettes sont posées, n’importe quel passant peut en ouvrir un, et chaque tiroir est vide. Nos vérifications ont essayé chaque tiroir et n’ont rien trouvé dans aucun, ce qui est un compte rendu exact d’un classeur vide.

À quel point il est vide, les chiffres le disent. Seules 17 des 1 790 citaient un projet Supabase quelque part dans le code qu’elles publient, et sur les 17 notre vérification de base de données n’a pas obtenu de réponse qu’elle pouvait juger, donc le nombre de tables lisibles sur v0 est de zéro sur zéro. Les 1 790 étaient servies depuis vusercontent.net, que Vercel décrit dans sa demande d’inscription à la Public Suffix List comme l’endroit « où nous hébergeons le contenu soumis par les utilisateurs » de v0. Une application que vous publiez part vers une adresse vercel.app ou un domaine à vous, où rien ne la signale comme v0 de l’extérieur, donc celles-là ne sont pas dans le compte. La méthode et les données complètes sont dans le rapport.

« v0 est-il sûr » recouvre donc trois questions :

  1. L’outil. Ce que v0 vérifie dans le code qu’il écrit, et ce qu’il refuse de publier. Cette partie relève de Vercel, et elle est documentée.
  2. L’aperçu. Le classeur dans la salle d’exposition, à son adresse vusercontent.net. Toutes les applications que nous avons mesurées en étaient à ce stade.
  3. L’application que vous remplissez. Le même code une fois qu’il contient les dossiers de vos clients, ou qu’il tourne sur votre propre domaine. Presque rien de ce que nous avons mesuré n’en était arrivé là.

Ce que couvre la sécurité de v0 avant la publication

Trois choses, et la documentation de v0 nomme chacune d’elles.

Il relit le code qu’il a écrit. La page sécurité de v0 dit que tout code généré « passe par une analyse de sécurité avant son exécution », et que v0 « analyse l’usage de NEXT_PUBLIC_ et avertit les utilisateurs des risques de sécurité possibles ». NEXT_PUBLIC_ est le préfixe qui dit à Next.js, le framework dans lequel v0 écrit, de mettre une valeur dans le code que chaque visiteur télécharge. Ce que ce préfixe fait à une clé fait l’objet d’un article à part.

Il refuse certains déploiements. En août 2025, Vercel a écrit que v0 avait bloqué plus de 17 000 déploiements dans les 30 jours précédents pour des secrets exposés seulement, et plus de 100 000 déploiements non sûrs depuis son lancement. Ce sont les chiffres de Vercel sur le blocage de Vercel, qui s’applique aux déploiements sur Vercel. Une partie de notre zéro peut être l’œuvre de ce blocage. De l’extérieur, nous ne pouvons pas dire quelle part.

L’intégration Supabase met le préfixe au bon endroit. Connectée via le Vercel Marketplace, elle ajoute une douzaine de variables d’environnement, et deux seulement portent NEXT_PUBLIC_ : l’adresse du projet et la clé publiable, toutes deux faites pour être publiques. SUPABASE_SECRET_KEY et le mot de passe de la base restent sans préfixe, sur le serveur.

L’intégration Supabase ajoute douze variables. Deux atteignent chaque visiteur, et toutes deux sont faites pour : l’adresse du projet et la clé publiable.

Pourquoi il manque des en-têtes de sécurité à un aperçu v0

Parce que c’est le domaine d’aperçu de v0 qui les fixe : chaque application qui s’y trouve reçoit la même réponse, et vous ne pouvez pas la changer depuis un aperçu.

Les en-têtes de sécurité sont des instructions qu’un site envoie avec chaque page : toujours utiliser HTTPS, ne pas laisser un autre site afficher cette page dans la sienne, ne pas deviner de quel type de fichier il s’agit. C’est celui qui sert la page qui les envoie. Les aperçus que nous avons ouverts le 3 octobre 2026 envoyaient un des cinq que cherche notre vérification, celui qui impose HTTPS, et aucun des quatre autres. C’est la trouvaille sur les 1 790 applications v0, et c’est la seule.

La salle d’exposition décide de ses propres portes et alarmes, et vous ne pouvez pas les recâbler pour un seul classeur posé chez elle. Dès que vous publiez, le classeur est dans votre bureau, et les en-têtes sont un réglage dans vercel.json ou dans votre configuration Next.js. Ce que fait chaque en-tête, et les deux qui ne coûtent rien fait l’objet d’un autre article.

Un aperçu vusercontent.net est-il public ?

Traitez-le comme public. Quiconque a l’adresse peut l’ouvrir, et les adresses circulent.

Chacun des 1 790 s’est ouvert pour nous sans connexion, et nous n’avons eu à en deviner aucun : leurs adresses venaient d’une archive web publique qui avait déjà enregistré une copie de chacun. Les réglages de partage de v0 décident qui peut voir votre chat : privé par défaut, puis votre équipe, toute personne qui a le lien, ou tout le monde sur le web. La documentation ne dit pas que ces réglages s’étendent à l’aperçu.

Un aperçu, c’est donc le classeur dans la salle d’exposition. Cela convient pour montrer le design à quelqu’un et pas pour les vrais dossiers de qui que ce soit. Vercel a inscrit vusercontent.net sur la Public Suffix List en septembre 2024, ce qui fait que les navigateurs traitent chaque aperçu comme un site à part : un aperçu ne peut pas poser de cookies pour tous les autres. Cela tient les aperçus séparés les uns des autres, et ne fait rien pour garder le vôtre privé.

Si vous êtes ici parce que quelqu’un vous a envoyé un lien vusercontent.net : le domaine appartient à Vercel, et la page qu’il héberge a été faite par la personne qui l’a demandée par prompt. Le 1er juillet 2025, Okta a signalé des attaquants qui utilisaient v0 pour construire des copies de vraies pages de connexion, et Vercel a restreint l’accès à celles qu’il a trouvées. Ne tapez pas de mot de passe dans un formulaire de connexion à une telle adresse si vous ne l’attendiez pas.

Ce qui change quand vous connectez Supabase à v0

Vous commencez à remplir les tiroirs, et les vérifications revenues vides sur v0 commencent à avoir quelque chose à vérifier.

v0 ajoute Supabase en un clic et, selon les termes de sa propre documentation, il « peut générer et exécuter du SQL. Cela vous permet de créer, modifier et supprimer des tables ». C’est ainsi que vos tables sont créées. Chaque table est un tiroir, et la Row Level Security est sa serrure : un réglage par table qui décide quelles lignes la clé publiable de votre page peut lire. Cette clé est faite pour être publique, donc la serrure est la seule chose qui décide de ce qu’un inconnu obtient.

Supabase pose cette serrure par défaut sur les tables créées dans son Table Editor, et la laisse de côté sur les tables créées en exécutant du SQL, ce qui est la manière dont v0 les crée.

Une table créée dans le Table Editor de Supabase arrive verrouillée. Une table créée en exécutant du SQL, ce que fait v0, arrive avec le cadenas ouvert.

C’est là que sont tombées les trouvailles graves chez tous les autres builders. Sur les 3 553 applications Lovable dont nous avons pu interroger la base, 2 017 ont rendu des lignes à une requête sans connexion, et les chiffres de Lovable montrent à quoi ressemblent les résultats d’un builder une fois qu’il y a des dossiers dans les tiroirs. Une serrure que n’importe quelle clé ouvre n’en est pas une non plus : une politique qui dit using (true) laisse passer tout le monde pendant que le tableau de bord affiche la table comme protégée. La RLS est activée et votre table reste publique raconte toute l’histoire.

Si vos données sont plutôt derrière des routes auxquelles répond votre propre code serveur, la même question se pose pour ces routes : ce que signifie un endpoint d’API ouvert.

Ce qui change quand vous publiez ou déployez vous-même

Le classeur quitte la salle d’exposition pour votre bureau, et les décisions que prenait le domaine de v0 deviennent les vôtres.

Publier depuis v0 crée un projet Vercel et pose trois questions, d’après la documentation de déploiement de v0 : le nom du projet, qui peut accéder à l’application déployée, et le domaine, soit une adresse vercel.app, soit le vôtre. Prenez le temps sur la deuxième. Les options que vous voyez dépendent de votre offre, et réserver l’application à votre équipe ou la mettre derrière un mot de passe tant que vous ne l’avez pas vérifiée garde les inconnus dehors pendant que vous regardez.

Trois choses passent de votre côté quand vous publiez :

  • Les en-têtes. Les portes et alarmes du bureau, c’est vous qui les réglez maintenant.
  • Les variables d’environnement. Elles vivent dans les réglages de votre projet, et c’est dans cette liste qu’une clé reçoit le préfixe NEXT_PUBLIC_ ou non.
  • La vérification de votre déploiement, si vous quittez Vercel. Vercel décrit son blocage comme arrêtant des déploiements sur Vercel, donc le code que vous téléchargez et hébergez ailleurs part sans cette vérification.

Dans les deux cas, vous êtes sorti de l’échantillon que nous avons mesuré. Une application v0 sur son propre domaine avec une base de données derrière ressemble davantage aux applications Bolt que nous avons mesurées qu’à ces 1 790 aperçus.

Comment vérifier votre propre application v0

Cinq choses, et les trois premières ne comptent qu’une fois que vous avez connecté une base de données ou publié. Utilisez une fenêtre privée, pour que votre propre connexion ne réponde pas à la place d’un inconnu.

  1. Lisez vos variables d’environnement. Dans v0, elles sont dans le menu du projet, sous Settings, Environment Variables. Tout ce qui commence par NEXT_PUBLIC_ est dans le code que chaque visiteur télécharge. L’adresse d’un projet et une clé publiable y ont leur place. Une clé qui vous facture, SUPABASE_SECRET_KEY et tout ce qui contient un mot de passe, jamais. Si l’une d’elles a déjà porté le préfixe, faites-la d’abord tourner chez le fournisseur, parce que l’ancienne valeur continue de fonctionner tant que vous ne l’avez pas fait.
  2. Lisez la serrure de chaque table. Dans Supabase, ouvrez Authentication → Policies et descendez la liste. Une table avec la Row Level Security désactivée est lisible par quiconque a l’adresse de votre projet, et cette adresse est dans votre page. Une politique qui autorise tout le monde compte comme désactivée.
  3. Choisissez qui peut la voir au moment de publier. Votre équipe seulement, ou un mot de passe, tant que les deux premiers points ne sont pas faits.
  4. Réglez vos en-têtes une fois le domaine à vous. Deux d’entre eux tiennent en une ligne chacun.
  5. Puis regardez depuis l’extérieur. Notre scan lance les neuf vérifications contre l’adresse publiée comme le ferait un inconnu, prend environ 20 secondes et ne demande aucun compte : scannez votre application gratuitement.

Un scan depuis l’extérieur ne voit pas le code que v0 a écrit, ni le chat dans lequel vous l’avez écrit, ni une table que vos pages ne mentionnent jamais. Les vérifications de v0 voient le code de l’intérieur et ne voient pas ce qu’un inconnu obtient de l’adresse. Lancez celles de v0 pendant que vous construisez, regardez depuis l’extérieur après la publication et, si les deux ne sont pas d’accord sur la lisibilité d’une table, fiez-vous à la réponse de l’extérieur, parce que c’est celle qu’obtient un inconnu. La version en langage simple pour cette plateforme est votre application v0 est-elle sûre ?.

Pour que cela reste vrai après la publication

Un A sur un aperçu décrit un aperçu. Le jour où vous connectez une base de données ou publiez sur votre propre domaine, votre note peut changer, et rien sur votre écran ne vous dit qu’elle a changé.

Reeve Monitor relance les neuf vérifications pour vous :

  • les neuf vérifications toutes les heures, sur trois applications au plus
  • si l’application répond, toutes les 60 secondes
  • un message quand un résultat change, pour qu’une nouvelle table ou une nouvelle clé n’attende pas que vous regardiez
  • un rapport mensuel de ce qu’il a vu

Monitor coûte €12 par mois au tarif public, avec sept jours gratuits avant le premier prélèvement. La page des tarifs est parfois en dessous du chiffre donné ici, jamais au-dessus.

Si votre application v0 garde ses données dans Supabase, Reeve Care conserve une copie de votre base Supabase.

  • une copie chiffrée chaque nuit, gardée là où votre projet ne peut pas l’atteindre
  • chaque copie vérifiée avant de compter, en dénombrant les lignes de chaque table
  • une restauration en un clic quand vous en avez besoin
  • vos fichiers téléversés aussi, dès que vous connectez un accès Storage
  • tout ce que fait Monitor

Care coûte €49 par mois au tarif public pour une application, avec les mêmes sept jours gratuits.

La documentation de v0 dit qu’il peut supprimer des tables autant qu’en créer, et aucune des neuf vérifications ci-dessus ne ramènerait les lignes de l’une d’elles. Le jour où un agent IA a supprimé une base de production montre à quoi cela ressemble de l’intérieur.

Que faire cette semaine

Que faire

  • Si votre application v0 est encore un aperçu, traitez son adresse comme publique et gardez-en les données de vraies personnes à l’écart.
  • Avant de connecter une base de données, décidez où vit chaque clé : NEXT_PUBLIC_ pour l’adresse du projet et la clé publiable, et rien près du navigateur pour tout le reste.
  • Après avoir connecté Supabase, lisez la politique de chaque table créée par v0, et traitez comme désactivée une politique qui autorise tout le monde.
  • Publiez pour votre équipe seulement ou derrière un mot de passe tant que ce n’est pas fait, puis vérifiez l’adresse publiée depuis l’extérieur.
  • Gardez une copie de votre base de données là où ni v0 ni votre projet ne peuvent l’atteindre, et vérifiez que la copie se restaure.

Commencez par les variables d’environnement, parce que ce sont elles qui décident de ce que chaque visiteur télécharge. Si vous hésitez encore entre plusieurs builders, quel builder d’applications IA est le plus sûr met les cinq côte à côte.

FAQ

v0 est-il sûr ?

Sur ce que nous avons pu mesurer, v0 est sorti plus propre que tous les autres builders scannés. Les 1 790 applications v0 en ligne ont eu A, et la seule trouvaille qu’elles partageaient était un réglage d’en-têtes de navigateur sur le domaine depuis lequel v0 sert les aperçus. Seules 17 citaient pourtant une base de données, et aucune de ces 17 n’a répondu à notre vérification de base de données, donc ce A décrit surtout des frontends sans rien derrière. Dès que vous connectez Supabase ou publiez sur votre propre domaine, les vérifications qui décident d’une note grave commencent à s’appliquer à vous.

Les applications v0 sont-elles sûres par défaut ?

Les parties que v0 contrôle sont en bon état. Sa documentation dit que le code généré passe par une analyse de sécurité avant de s’exécuter et qu’il avertit d’un usage risqué du préfixe NEXT_PUBLIC_, et en août 2025 Vercel a indiqué que v0 avait bloqué plus de 17 000 déploiements en 30 jours pour des secrets exposés. Ce qu’aucun réglage par défaut ne décide, c’est la serrure de vos tables. Supabase n’active pas la Row Level Security sur les tables créées en exécutant du SQL, et c’est ainsi que v0 les crée : lisez donc la politique de chaque table après avoir connecté une base de données.

Une URL d’aperçu vusercontent.net est-elle publique ?

Traitez-la comme publique. Chacun des 1 790 aperçus v0 que nous avons scannés s’est ouvert sans connexion, et nous avons trouvé leurs adresses dans une archive web publique. Les réglages de partage de v0 contrôlent qui peut voir votre chat, et sa documentation ne dit pas qu’ils s’appliquent à l’aperçu. Gardez les données de vraies personnes hors d’un aperçu et, au moment de publier, choisissez une visibilité réservée à l’équipe ou protégée par mot de passe jusqu’à ce que l’application soit prête pour des inconnus.

vusercontent.net est-il sûr ?

Le domaine est réel et appartient à Vercel, qui l’utilise pour héberger ce que les gens génèrent avec v0. Mais la page à une adresse donnée a été faite par la personne qui l’a demandée par prompt, et en juillet 2025 Okta a signalé des attaquants qui utilisaient v0 pour construire des copies de pages de connexion. Vercel a restreint l’accès à celles qu’il a trouvées. Si un lien que vous n’attendiez pas ouvre un formulaire de connexion à une adresse vusercontent.net, n’y tapez pas de mot de passe.

Qu’est-ce qui change quand je connecte Supabase à v0 ?

Il y a désormais des données derrière votre frontend, donc les vérifications revenues vides sur les applications v0 commencent à avoir quelque chose à vérifier. v0 peut exécuter du SQL pour créer des tables, et Supabase n’active pas la Row Level Security sur les tables créées ainsi. Votre clé publiable est faite pour être dans la page, donc la politique de chaque table est la seule chose qui décide de ce qu’un inconnu peut lire. Sur les 3 553 applications Lovable dont nous avons pu interroger la base, 2 017 ont rendu des lignes à une requête sans connexion.

Qu’est-ce qui change quand je déploie moi-même le code de v0 ?

Trois choses deviennent les vôtres. Les en-têtes de sécurité que choisissait le domaine d’aperçu de v0 deviennent un réglage dans vercel.json ou dans votre configuration Next.js. Vos variables d’environnement, et celles qui portent le préfixe NEXT_PUBLIC_, vivent dans votre propre projet. Et le code que vous téléchargez et hébergez ailleurs que chez Vercel ne passe plus par la vérification de déploiement que Vercel décrit pour v0. Regardez l’adresse publiée depuis l’extérieur dès qu’elle est en ligne.

Écrit par

Vlad Tkachenko

Fondateur de Reeve

Je passe mes journées à examiner des applications créées avec Lovable, Bolt, v0, Cursor et Replit, et la courte liste d'erreurs qui y reviennent sans cesse.

En savoir plus sur l'auteur

À lire ensuite

Tous les articles

Vous ne savez pas où en est votre propre application ?

Lancez une analyse gratuite et obtenez une note claire de A à F en une vingtaine de secondes. Sans compte, sans carte.

Analyser mon application

Vérification externe automatisée, pas un audit complet. L'absence de problème n'est pas une garantie de sécurité.