La checklist de sécurité du vibe coding, en neuf vérifications

Vous êtes sur le point d’envoyer l’adresse de votre appli à quelqu’un, et une petite voix vous dit de vérifier avant. Alors vous cherchez une checklist de sécurité du vibe coding et vous en trouvez une de vingt-cinq points, écrite par quelqu’un qui suppose que vous savez déjà ce qu’est une Content Security Policy.

Voici la partie que liste après liste se trompe : l’essentiel de ce qu’elles contiennent ne peut pas être vérifié. « Utilisez des mots de passe forts » est un conseil. « Nettoyez le code mort » est du rangement. « Suivez le principe du moindre privilège » est une phrase. Aucun n’a de test, donc aucun ne peut être terminé, et une liste que vous ne pouvez pas terminer est une inquiétude avec des numéros dessus.

Celle-ci tient en neuf points. Neuf est le nombre de choses que n’importe qui peut vérifier de l’extérieur sur une appli en ligne, sans votre mot de passe, sans votre dépôt et sans votre compte Supabase. Chacun a un test que vous pouvez faire vous-même et chaque test revient par oui ou par non.

Voyez cela comme le tour qu’un pilote fait autour d’un avion avant un vol. Il est court, tout ce qui s’y trouve est visible depuis le tarmac, et il ne remplace rien du carnet d’entretien. La dernière section de cet article parle du carnet.

Que doit contenir une checklist de sécurité du vibe coding ?

Neuf questions, et ce sont les neuf qu’un inconnu pourrait poser à votre appli cet après-midi, que vous ayez vérifié ou non.

Notre propre scanner de sécurité gratuit fait les neuf sur n’importe quelle URL en ligne en 20 secondes environ et sans compte, ce qui est le plus rapide pour le premier passage. Il lit, il ne se connecte jamais et il n’écrit jamais rien. Chaque point ci-dessous reste quelque chose que vous pouvez vérifier à la main, et les tests sont écrits noir sur blanc pour que vous puissiez confronter une ligne de notre rapport à votre propre tableau de bord.

Les quatre à faire avant de partager l’adresse

Clés secrètes, règles de base de données, fichiers privés et buckets de stockage. Sur ces quatre-là, ce qui est exposé, ce sont vos données ou votre argent, et les quatre vous reviennent à vous et non à votre hébergeur.

Trois d’entre eux sont les seules vérifications de tout l’ensemble capables de signaler un résultat critique, et la quatrième est celle où ce qui est exposé est ce que vos utilisateurs ont téléversé. Entre le 12 et le 14 août 2026, nous avons passé les neuf vérifications sur 30 998 applis de vibe coding en ligne, et les chiffres de chaque section ci-dessous viennent de ce passage.

1. Une clé secrète est-elle dans le code que votre appli envoie ?

Cherchez dans tout votre projet sk_, sb_secret_, service_role et AKIA. Une correspondance dans quoi que ce soit que le navigateur télécharge est le signalement.

Tout ce dont votre appli a besoin pour tourner dans un navigateur arrive dans ce navigateur, donc une clé qui s’y trouve arrive aussi. Certaines clés y ont leur place : une clé Supabase anon ou sb_publishable_ est une adresse et non une permission, et la trouver est correct. Quelles clés sont sûres dans un frontend et lesquelles ne le sont pas est cette distinction en entier.

Une clé secrète est l’autre espèce. Une clé Supabase sb_secret_ ou service_role ignore toutes les règles de table que vous avez jamais écrites. Une clé Stripe sk_live_ déplace de l’argent. Nous avons trouvé une clé de cette classe sur 52 applis sur 30 998, ce qui est rare et reste la pire chose de cette liste quand cela arrive. Si la vôtre en fait partie, faites-la tourner avant toute autre chose : supprimer la clé de votre code laisse l’ancienne valeur en service.

2. Un inconnu peut-il lire votre base de données ?

Dans Supabase, ouvrez le Security Advisor. Chaque entrée disant qu’une table est publique mais que la sécurité par lignes n’est pas activée est une table qui répond à quiconque demande, et cet avertissement précis a son propre article.

Row Level Security est la règle qui décide, ligne par ligne, qui peut voir quoi. Sans elle, la clé publique qui se trouve dans votre appli suffit à lire la table, et cette clé est dans le navigateur de chaque visiteur par conception.

C’est le signalement sérieux le plus fréquent de tout l’ensemble : 2 096 des 3 680 applis dont le projet Supabase nous a répondu, soit 57 %, avaient au moins une table qui livrait des lignes à une requête sans personne connecté. L’activer sur chaque table est le correctif. L’advisor lit vos réglages et non les réponses de votre base, alors terminez en vérifiant depuis l’extérieur : une table peut avoir le réglage actif et une règle qui laisse quand même tout le monde passer.

3. N’importe qui peut-il télécharger vos fichiers privés ?

Ouvrez votreappli.com/.env et votreappli.com/.git/config dans une fenêtre privée. Les deux devraient refuser de s’ouvrir.

Un fichier .env est chacune des clés que vous croyiez à l’abri sur le serveur, dans une liste toute simple, à une adresse devinable. Un répertoire .git est l’historique de votre projet. Ni l’un ni l’autre n’est censé être servi, et tous deux le sont parfois, en général parce qu’un build a recopié un dossier qu’il n’aurait pas dû.

C’est la chose la plus rare que nous trouvions : 8 applis sur 30 749. C’est aussi cinq secondes de travail pour l’écarter, et c’est d’où viennent les fuites les plus dommageables quand cela arrive.

4. Vos buckets de stockage listent-ils ce qu’ils contiennent ?

Dans Supabase, ouvrez Storage. Lisez la colonne Public sur chaque bucket, puis ouvrez les règles de tout bucket qui contient quelque chose qui n’est pas destiné à tout le monde.

Deux choses différentes se jouent ici et on les confond facilement. Un bucket public sert n’importe quel fichier dont quelqu’un connaît déjà le nom. Un bucket listable livre les noms, ce qui transforme « il faudrait deviner » en un répertoire des téléversements de vos utilisateurs. Notre vérification teste la seconde, parce que c’est elle qui change ce qu’un inconnu peut réellement faire.

792 applis sur 27 269 avaient un bucket qui s’est listé devant nous sans connexion. Ce qu’un inconnu tire de cette liste est la version longue, et le correctif est en général un interrupteur plus une règle.

Les cinq qui peuvent attendre d’avoir des utilisateurs

En-têtes, source maps, vos propres adresses d’API, le certificat et le domaine. Trois d’entre eux sont en général posés par celui qui héberge votre appli, et deux sont des dates dans un calendrier.

Aucun ne livre à lui seul une ligne de votre base de données, et c’est pour cela qu’ils sont dans le second groupe. L’un des cinq mérite d’être avancé si votre appli a son propre backend, et il est signalé plus bas.

5. Les en-têtes de sécurité du navigateur sont-ils activés ?

C’est le seul point de la liste sans version que vous puissiez faire depuis la barre d’adresse. Un scan les lit, ou vous ouvrez les outils de développement de votre navigateur, allez dans l’onglet Réseau, cliquez la première requête et lisez les en-têtes de réponse.

Ce sont de petites instructions au navigateur : ne charge cette page qu’en HTTPS, refuse d’être encadrée par un autre site, ne devine pas les types de fichier. Leur absence n’expose rien en soi. Elle retire des protections qui rendent d’autres attaques plus difficiles.

Presque personne ne passe ce point et presque personne ne le peut. Il en manquait au moins un à 30 756 applis sur 30 981, et sur un sous-domaine de builder le réglage appartient à la plateforme. Si vous pouvez faire quelque chose pour les vôtres dépend entièrement de l’endroit où votre appli est hébergée.

6. Votre code source d’origine est-il publié ?

Ouvrez votre appli en ligne, ouvrez les outils de développement de votre navigateur et regardez le panneau Sources. Si vos propres fichiers y figurent avec le code que vous avez écrit et les commentaires que vous avez laissés, les source maps sont parties avec le build.

Une source map est une table de traduction qui ramène le fichier compressé envoyé par votre appli à du code lisible. Les développeurs s’en servent pour déboguer un site en ligne. Publiée sur internet, elle signifie que n’importe qui peut lire votre appli telle que vous l’avez écrite.

3 885 applis sur 30 987 ont publié les leurs. Ce n’est pas une fuite en soi, et cela en devient une quand le code contient quelque chose dont vous supposiez que personne ne le lirait. Ce qu’expose une source map publiée couvre la différence et le réglage de build qui l’éteint.

7. Vos propres adresses d’API répondent-elles à un inconnu ?

Copiez l’une des adresses d’API de votre appli depuis l’onglet Réseau, puis ouvrez-la dans une fenêtre privée où vous n’êtes pas connecté. Regardez ce qui revient.

C’est le point à avancer si votre appli a son propre backend, parce que tout ce qu’une adresse remet à une requête sans connexion est public, quelle que soit l’allure de la page qui se trouve devant. 3 852 applis sur 30 926 en avaient au moins une.

Le réglage apparenté est CORS, qui décide quels autres sites web peuvent appeler votre appli depuis le navigateur d’un visiteur. Un joker à cet endroit est souvent très bien et parfois non, et lequel des deux vous avez mérite d’être lu avant de changer quoi que ce soit.

8. Votre certificat est-il sur le point d’expirer ?

Cliquez le cadenas dans la barre d’adresse, ouvrez le certificat et lisez la date « Valide jusqu’au ».

Presque tous les hébergeurs les renouvellent automatiquement et presque tous y arrivent. 32 applis sur 30 851 avaient un certificat expiré, sur le point d’expirer ou non fiable. Quand cela échoue, les visiteurs reçoivent un avertissement du navigateur en pleine page leur disant que votre site n’est pas sûr, et la plupart s’en vont.

9. Votre domaine est-il renouvelé ?

Connectez-vous chez votre bureau d’enregistrement, lisez la date d’expiration et vérifiez que le renouvellement automatique est actif et que la carte derrière n’a pas expiré.

C’est le point le moins technique de la liste et le seul qui puisse retirer votre appli d’internet complètement. 55 applis sur 30 980 avaient un domaine expiré ou sur le point d’expirer. Un nom échu peut aussi être enregistré par quelqu’un d’autre, avec chaque lien que l’on a jamais fait vers lui.

Ce que portent les autres checklists et qui n’est pas une vérification de sécurité

Les sauvegardes, la surveillance des erreurs, le code mort et les conseils sur les mots de passe. La première est celle qui risque le plus de vous coûter quelque chose, et ce n’est pas une vérification de sécurité, parce que rien à l’extérieur de votre appli ne peut dire si vous en avez une.

C’est la raison honnête de son absence parmi les neuf. Un scanner lit votre site en ligne ; une sauvegarde est une copie de votre base de données posée ailleurs, et aucun regard porté de l’extérieur sur votre appli ne peut dire si elle existe, si elle est à jour ou si elle se restaurerait. Elle a quand même sa place sur votre liste. Elle a sa place sur le genre de liste que l’on tient, plutôt que sur celui que l’on parcourt.

Les sauvegardes propres à Supabase dépendent de votre formule et restent à l’intérieur de votre compte Supabase, ce qui va très bien jusqu’au jour où le problème est le compte. Les trois chemins vers une copie qui vous appartient expose ce que chacun couvre.

Si vous préférez que cela se passe sans vous, c’est ce que fait Reeve Care. Il prend une copie de votre base Supabase selon un rythme fixé par la formule choisie, chaque nuit sur l’offre d’entrée et jusqu’à quatre fois par jour sur la plus haute, relit chaque copie avant qu’elle ne compte comme sauvegarde, et la range là où Supabase n’atteint pas. Jusqu’où vous pouvez remonter est fixé de la même façon. Restaurer est un bouton, et il prend un instantané de l’état actuel avant de commencer, si bien qu’appuyer dessus en panique ne peut pas détruire ce que vous cherchiez à sauver. Les fichiers téléversés suivent aussi, dès que vous connectez un accès Storage, demandé séparément parce que c’est la seule clé que nous détenons qui peut écrire : Supabase n’émet pas de clé en lecture seule pour les fichiers. Care commence à €49 par mois pour une appli, et c’est un prix de liste, donc la page des tarifs est parfois sous le chiffre indiqué ici et jamais au-dessus. Comment une copie est prise, vérifiée et remise en place est dessiné étape par étape sur la page des sauvegardes Supabase.

Le reste de ce que portent ces listes est du vrai travail et pas celui-ci. La surveillance des erreurs vous dit quand votre appli casse, et c’est de l’exploitation. « Retirez les dépendances inutilisées » est du rangement. « Utilisez des mots de passe forts » vaut pour tout ce à quoi vous vous êtes jamais connecté.

À quelle fréquence refaire tout cela ?

Après chaque déploiement qui a touché vos règles de base de données, vos clés ou vos réglages de build. Si cela ressemble à la plupart des déploiements, c’est bien le cas, et c’est là le vrai problème d’une checklist que l’on parcourt une fois.

Le tour de l’avion se fait avant chaque vol exactement pour cette raison. Row Level Security est coupée à minuit pour qu’une page charge et personne ne la remet. Une clé est collée dans le frontend pour sortir une fonctionnalité avant une démo. Un bucket est ouvert pour un téléversement et reste ouvert. Chacune de ces choses est un mardi ordinaire, et chacune suffit à transformer un résultat propre en résultat sérieux.

Reeve Monitor existe pour ce trou. Il repasse les neuf vérifications toutes les heures sur trois applis au maximum, regarde toutes les 60 secondes si l’appli répond, vous prévient le jour où un résultat change au lieu d’attendre que vous regardiez, et envoie un rapport mensuel en langage clair. Il coûte €12 par mois au prix de liste, avec sept jours gratuits avant toute facturation, et la page des tarifs est parfois sous le chiffre indiqué ici et jamais au-dessus. Monitor surveille et rien d’autre. Les sauvegardes sont la formule Care au-dessus, et Care garde une copie d’une base Supabase et de rien d’autre.

Ce que rien de tout cela ne prouve

Que votre appli est sécurisée. Neuf vérifications qui reviennent propres veulent dire que neuf questions posées depuis l’extérieur sont revenues propres le jour où vous les avez posées.

Quatre choses restent invisibles pour chaque point de cette liste, parce qu’aucune ne quitte jamais votre serveur. Votre code serveur, y compris les fonctions de base de données et les edge functions que personne de l’extérieur ne peut lire. Les variables d’environnement que vous avez gardées hors du navigateur, ce qui est exactement leur place et aussi pourquoi un scan ne peut pas confirmer qu’elles sont bien rangées. Votre historique de versions, où une clé que vous avez commitée en mars et retirée en avril est toujours assise. Et la logique propre de votre appli, par exemple si un utilisateur connecté peut ouvrir la commande d’un autre en changeant un chiffre dans l’adresse.

Ce qu’un scan par URL peut voir et ne peut pas voir parcourt cette frontière comme il faut, y compris les trois outils qui lisent des choses différentes et l’endroit où chacun est aveugle.

Quoi faire tout de suite

Si votre appli garde ses données dans Supabase, la version écrite autour de ce seul stack est le guide des applis Supabase. Et si vous préférez quelque chose à cocher plutôt qu’à lire, la checklist de sécurité en 10 minutes est la version interactive.