Aller au contenu

Sécurité des applis vibe-codées : l'état des lieux 2026

30 998applis en ligne
9vérifications passives
12–14 aoûtfenêtre d’analyse
19 août 2026première édition
Étude Reeve

Nous avons cherché des applis en ligne créées avec Lovable, Bolt, v0, Replit ou Base44, puis passé chacune par les mêmes neuf vérifications que n'importe qui peut lancer gratuitement depuis la page d'accueil de Reeve. Cette page est le relevé.

Votre appli est peut-être dans cet échantillon. Rien ici ne la nomme, donc le seul moyen de voir où elle en est est de lui passer les mêmes neuf vérifications

Uniquement un regard de l'extérieur. Nous lisons ce que le navigateur d'un visiteur lit déjà : le code que l'appli livre, les en-têtes qu'elle renvoie, les points d'accès que son propre code désigne. Aucune connexion, aucun mot de passe deviné, rien de téléchargé. Méthode ↓

Aucune appli n'est nommée ici ni dans le fichier de données. Chaque chiffre porte la méthode qui l'a produit, et le fichier en bas de page rassemble tous les agrégats dans un tableau si vous voulez refaire les calculs.

Chaque appli, notée

452 applis, environ une sur 69, sont en D ou F
A23 62176% , note A, 23 621 applis
B4 95816% , note B, 4 958 applis
C1 9676% , note C, 1 967 applis
D4441% , note D, 444 applis
F8<1% , note F, 8 applis

Six chiffres qui disent l'essentiel

Ces six chiffres sont le rapport. Tout ce qui suit, c'est la base sur laquelle chacun repose, et comment nous l'avons obtenue.

  1. En-têtes de sécurité1/6
    99%

    des 30 998 applis analysées présentaient au moins un constat. La plupart étaient modérés, et il manque à presque toutes des en-têtes de sécurité du navigateur.

  2. Accès à la base de données2/6
    57%

    des applis sous Supabase que nous avons pu atteindre laissaient un inconnu lire au moins une table sans se connecter : 2 096 sur 3 680.

  3. Accès à la base de données3/6
    394

    applis avaient une table lisible dont le nom ressemble à des données personnelles : users, profiles, orders. Une requête, sans mot de passe.

  4. Secrets exposés4/6
    1sur23

    applis livrent une clé secrète dans leur code public : 1 332 au total. Seulement 3 ont livré la clé maîtresse de la base, plus rare que la panique ne le laisse croire.

  5. Source maps5/6
    13%

    publient des source maps : le code d’origine de l’appli, lisible dans les outils de développement de n’importe quel navigateur. Cela fait 3 885 applis.

  6. Répartition des notes6/6
    76%

    obtiennent la note A. Les bases tiennent le plus souvent, et les échecs sérieux se concentrent au même endroit : la base de données.

Les réglages par défaut des plateformes échouent presque partout, et la plupart de ces échecs sont modérés. Ce que seule la personne qui a construit l'appli peut changer échoue bien plus rarement, et c'est ce qui pose les données d'autres gens sur l'internet ouvert.

Comment ces applis sont notées, de A à F

Reeve note une appli comme un bulletin scolaire. Les points sont retirés d'un total de cent selon la gravité. Ensuite, le constat le plus grave pose un plafond : avec un constat critique, l'appli ne peut pas dépasser D ; avec un constat élevé, elle ne peut pas dépasser C.

Les notes de toutes les applis que nous avons pu classer

23 621 · 76% , note A, 23 621 applis
4 958 · 16% , note B, 4 958 applis
1 967 · 6% , note C, 1 967 applis
444 · 1% , note D, 444 applis
8 · <1% , note F, 8 applis

Cela fait 452 applis avec un trou qu'un inconnu peut franchir aujourd'hui.

La plupart des applis se placent en A ou B. La tranche D et F est petite. Ce sont les applis où un inconnu peut déjà lire les lignes de quelqu'un d'autre.

Ce que nous avons vérifié, et combien d'applis échouent à chaque vérification

Chaque vérification pose une question sur l'appli vue de l'extérieur, et chacune est comptée sur les applis où elle a obtenu une réponse. Une appli qu'une vérification n'a pas pu atteindre sort de la base de cette vérification au lieu d'être comptée comme saine. Le scan dit de ces applis qu'il n'a pas pu les vérifier, et cette page fait de même.

Faites défiler sur le côté pour voir la part et le cas le plus grave.

Constats par vérification
VérificationApplisSurPartCas le plus grave
En-têtes de sécuritéProtections du navigateur que la plateforme d’hébergement devrait envoyer30 75630 98199%jusqu’à Moyen
Partage entre sitesL’API de l’appli répond à n’importe quel site qui demande6 86730 92622%jusqu’à Élevé
Source mapsLe code d’origine publié à côté de l’appli3 88530 98713%jusqu’à Moyen
Accès à la base de donnéesTables de la base lisibles sans se connecter2 09626 2498%jusqu’à Critique
Secrets exposésDes clés qui appartiennent à un serveur, envoyées aux navigateurs1 33230 9984%jusqu’à Critique
Espaces de stockageUn stockage de fichiers que n’importe qui peut lister79227 2693%jusqu’à Élevé
Renouvellement du domaineEnregistrement bientôt échu, ou déjà échu5530 980<1%jusqu’à Élevé
Certificat SSLCertificat expiré, sur le point d’expirer ou non fiable3230 851<1%jusqu’à Élevé
Fichiers privésFichiers de configuration et sauvegardes laissés à des chemins publics830 749<1%jusqu’à Critique

Chaque part porte sur les applis auxquelles cette vérification a pu répondre. Le point est la pire forme de ce problème vue dans la ligne, pas la forme habituelle.

Deux lignes font plus peur qu'elles ne le devraient. Les en-têtes de sécurité sont des instructions que la plateforme d'hébergement envoie au navigateur, et qu'il en manque un laisse une famille d'attaques avec un obstacle de moins devant elle. Une source map publiée, c'est le code d'origine de l'appli posé à côté de la version compilée : elle montre à un attaquant où chercher, et ne livre rien d'elle-même.

Une ligne peut aussi paraître grave parce qu'une poignée d'applis y ont livré quelque chose de sérieux pendant que les autres livraient quelque chose d'ordinaire. Le fichier de données détaille chaque ligne par type de clé pour qu'on voie laquelle est laquelle.

Plus de la moitié des applis Supabase vérifiables laissent lire leurs tables

C'est le chiffre sur lequel nous sommes sans cesse revenus.

Un projet Supabase est ouvert sur internet par conception. L'appli qui tourne dans le navigateur parle directement à la base de données, avec une clé faite pour être publique, et ce qui se tient entre un inconnu et les lignes, c'est Row Level Security : une règle sur chaque table. Désactivez cette règle, ou écrivez une politique qui laisse tout le monde entrer, et n'importe quelle table du projet se lit avec une seule requête et sans mot de passe.

57% 2 096 sur 3 680

8 429 applis de ce relevé désignent un projet Supabase. Notre vérification a obtenu une réponse de 3 680 d’entre elles ; les autres sont derrière des backends que nous ne sondons pas, donc nous n’en disons rien. Sur ces 3 680, 2 096 avaient au moins une table qu’un inconnu peut lire avec une seule requête et sans mot de passe.

Moins de la moitié des applis qui désignent un projet Supabase peuvent être vérifiées. Certaines font passer le trafic de leur base par leur propre backend, où une vérification venue de l'extérieur ne peut pas suivre ; nous n'en disons donc rien du tout. La part ci-dessus porte sur les applis qui ont répondu.

1 702 applis exposent des tables aux noms génériques ou techniques : settings, content, logs.

394 applis exposent des tables dont le nom évoque des données personnelles : users, profiles, orders, messages.

La répartition est la partie utile. Une table lisible appelée settings ou content est une erreur. Une table lisible appelée users, profiles ou orders, ce sont les données personnelles d'autres gens sur l'internet ouvert, et la personne qui a construit l'appli les croit presque certainement privées.

La vérification ne lit jamais une ligne. Elle demande à la base combien de lignes seraient visibles et relit le compte dans un en-tête de réponse. Cela suffit à distinguer une table avec règle RLS d'une table sans règle, et la vérification ne va pas plus loin.

Les mêmes neuf vérifications, outil par outil

Chaque appli est regroupée selon l'outil avec lequel elle a été publiée, et mesurée face aux autres applis de cet outil.

Faites défiler sur le côté pour voir les deux colonnes Supabase.

Par outil, uniquement sur les domaines de publication par défaut
OutilApplisAvec constatNotes D–FUtilisent SupabaseBase lisible
Lovable18 55499%2% 407 applis35%57%sur 3 553
Base445 438100%<1% 2 applis27%trop peu d’applis vérifiables pour publier une part
Replit3 04299%<1% 9 applis1%trop peu d’applis vérifiables pour publier une part
v01 790100%0% 0 applis1%trop peu d’applis vérifiables pour publier une part
Bolt1 123100%1% 15 applis24%77%sur 35

La dernière colonne est la part des applis Supabase de cet outil sur lesquelles notre vérification a pu répondre, avec cette base indiquée à côté. Un tiret signifie qu’il y avait trop peu d’applis vérifiables pour publier une part. Considérez-le comme un trou dans nos données, et n’en tirez aucune conclusion sur la sûreté de ces applis.

La ligne marquée fait passer le trafic de sa base de données par le backend de l’outil lui-même, où une vérification extérieure ne peut pas suivre. Ces applis restent non mesurées ici.

Les applis sur domaine personnalisé ne peuvent pas être rattachées à un outil depuis l’extérieur et restent hors de ce tableau.

L'essentiel de ce que compare ce tableau, ce sont des réglages par défaut. Personne ne choisit Lovable ou Bolt pour ses en-têtes de sécurité. C'est la plateforme qui les règle pour toutes les applis qu'elle héberge, donc un seul changement de sa part déplace une colonne entière de ce tableau.

Deux limites, avant que quiconque cite une ligne. Nous rattachons les applis à leur domaine de publication : une appli passée à un domaine personnalisé reste entièrement hors de ce tableau, et ce sont souvent les plus abouties. Et un outil qui fait passer le trafic de base de données par son propre backend ne peut tout simplement pas être vérifié de l'extérieur. Un blanc à cet endroit signifie que nous n'avons pas pu mesurer, et ne dit rien de la sûreté de ces applis.

Deux sortes de constats, deux sortes de corrections

Les constats de cette page tombent dans deux groupes, et les deux appellent des mains différentes.

Ce que la plateforme contrôle

jusqu’à Élevé

Quand presque toutes les applis hébergées au même endroit oublient le même en-tête, ce ne sont pas des dizaines de milliers de personnes qui font la même erreur. Cela vient avec l’hébergement, et un seul changement de la plateforme les corrigerait toutes.

  • En-têtes de sécurité99%
  • Source maps13%
  • Renouvellement du domaine<1%
  • Certificat SSL<1%

Ce que vous seul contrôlez

jusqu’à Critique

Aucune plateforme d’hébergement ne peut savoir lesquelles de vos tables doivent être publiques, ni quelle clé appartient à un serveur. Tous les constats critiques de ce rapport sont de ce côté.

  • Partage entre sites22%
  • Accès à la base de données8%
  • Secrets exposés4%
  • Espaces de stockage3%
  • Fichiers privés<1%

Le premier groupe est une décision produit prise dans une entreprise. Une seule modification d'un réglage d'hébergement par défaut déplace d'un coup toutes les applis de la plateforme, et c'est pourquoi ces lignes sortent si uniformes et sont les moins coûteuses à corriger.

Le second groupe revient à la personne qui a construit l'appli. Aucune plateforme d'hébergement ne peut savoir lesquelles de vos tables doivent être publiques, ni quelle clé appartient à un serveur. Tous les constats critiques de ce rapport sont dans ce groupe. Les guides de sécurité par outil et la checklist de lancement commencent tous les deux là.

Ce que les applis vibe-codées font bien

Nous avons aussi compté ce qui passe, sur les mêmes applis.

96%ne livrent aucun secret dans leur code public.

97%du stockage vérifiable est fermé aux visiteurs extérieurs.

99%servent un certificat valide.

Une clé publiable dans le frontend est à sa place. Nous les notons OK et nous expliquons pourquoi.

La dernière carte est celle sur laquelle les scanners génériques se trompent. Une clé publiable dans le frontend (une clé anon Supabase, une clé publiable Stripe) est exactement à sa place : elle est faite pour être lue, et la protection vit dans les règles derrière elle. La signaler envoie quelqu'un changer un réglage qui était déjà juste.

Comment nous avons mesuré, et où sont les limites

D'où viennent les applis

Trois listes, fusionnées et dédoublonnées : des applis que des gens ont publiées sur X et Reddit, des applis lancées sur Show HN, et des applis que nous avons énumérées depuis les domaines de publication des outils eux-mêmes. Les domaines de publication font l'essentiel de l'échantillon et sont la seule liste qui passe à l'échelle. Les deux autres ne trouvent que les applis dont quelqu'un a choisi de parler.

Les hôtes morts sont sortis en premier, et nous en avons jugé en lisant la page elle-même. Un déploiement supprimé répond souvent encore par un 200 OK parfaitement enjoué.

La règle du dénominateur

Chaque part de cette page porte sur les applis auxquelles cette vérification a pu répondre, jamais sur l'échantillon entier. Une vérification qui n'a pas pu atteindre une appli laisse cette appli hors de sa propre base, et ne la compte jamais comme saine. Les deux nombres à côté de chaque barre sont cette base, pour que chacun voie laquelle il lit.

56 applis ont renvoyé trop peu de choses pour être classées dans un sens ou dans l’autre. Elles restent en dehors de tous les chiffres de cette page plutôt que d’être comptées comme saines.

Les notes portent sur un nombre plus petit pour la même raison. Une appli qui a renvoyé trop peu de choses pour être classée sort de tous les chiffres ci-dessus au lieu d'être notée au jugé.

Ce que nous avons fait, et pas fait

  • Uniquement des lectures passives : les requêtes que le navigateur d'un visiteur fait déjà, plus les points d'accès publics que l'appli désigne elle-même.
  • La vérification de la base prend un compte de lignes dans un en-tête de réponse. Nous n'avons jamais lu une ligne, téléchargé un fichier, ouvert de session ni deviné un mot de passe.
  • Aucune appli n'est nommée, ni ici ni dans le fichier de données. Une liste d'applis accompagnées de leurs faiblesses est une liste de cibles, et nous n'en gardons pas sous une forme publiable.

Des limites à connaître

  • L'échantillon penche vers les applis récentes. Une appli passée à un domaine personnalisé ne peut pas être rattachée à un outil depuis l'extérieur, et ce sont souvent les plus établies.
  • La couleur d'une ligne marque le cas le plus grave que nous ayons vu, qui peut être une appli sur des centaines. Le fichier de données détaille chaque ligne par type de clé exact.
  • C'est une fenêtre de trois jours en août. Une appli corrigée la semaine suivante compte ici telle qu'elle était le jour où nous avons regardé.
  • Une vérification externe automatisée n'est pas un audit. L'absence de constat n'est pas une garantie.

Réutilisez ces chiffres

Journalistes, chercheurs et toute personne qui écrit sur le sujet peuvent réutiliser ces données en citant la source. Le fichier ci-dessous contient tous les agrégats de cette page dans un seul tableau à plat, et ne nomme aucune appli.

Reeve. The State of Vibe-Coded App Security 2026. 30 998 applis en ligne analysées 12 août 2026 – 14 août 2026. reeve.page/research/vibe-coded-app-security-2026

Données sous licence CC BY 4.0 : réutilisez-les librement en créditant Reeve par un lien. Le fichier contient tous les agrégats de cette page et ne nomme aucune appli.

10

Questions

Pouvez-vous me dire quelles applis avaient quels problèmes ?

Non. Des effectifs et des parts uniquement, jamais des noms, et le fichier de données contient exactement ce que la page affiche. Une liste d'applis accompagnées de leurs faiblesses est une liste de cibles, et nous n'en produirons pas.

Mon appli est peut-être dans ces données. Que dois-je faire ?

Analysez-la vous-même. Ce sont les mêmes neuf vérifications, cela prend une vingtaine de secondes, et vous obtenez votre note et ce qu'un inconnu voit déjà. Rien sur cette page n'identifie qui que ce soit : c'est donc le seul moyen de savoir où vous en êtes.

Une table de base de données lisible, est-ce vraiment si grave ?

Si n'importe qui sur internet peut tirer ces lignes avec une seule requête et sans mot de passe, oui. Une table lisible appelée settings est du laisser-aller. Une table lisible appelée users ou orders est une fuite de données que personne n'a encore remarquée.

Pourquoi comptez-vous les clés publiables comme correctes ?

La clé anon de Supabase est faite pour être publique. La protection, ce sont les règles de la base derrière elle, pas la clé elle-même. Les outils qui signalent ces clés apprennent aux gens à passer sur l'avertissement suivant, qui est peut-être celui qui compte.

Referez-vous cette étude ?

Oui. Les analyses continuent de tourner et la prochaine édition les suivra. Le fichier de données consigne la fenêtre d'où viennent ces chiffres, pour qu'une vieille copie ne puisse pas passer pour une copie à jour.

Où se situe votre appli ?

Les mêmes neuf vérifications, sur votre appli, gratuitement. Une note et un rapport en langage clair en environ 20 secondes.

Rapport de sécuritéyour-app.com
C

Note · Score 72/100

Clés secrètesUne clé secrète est exposée dans votre codeÉlevé
Protection de la base de donnéesLa sécurité au niveau des lignes est activéeOK
Analysez votre appli gratuitement