Pourquoi les applis vibe codées se ressemblent dans leurs failles
Un agent de code reçoit un objectif : que la fonctionnalité marche. Quand une règle d'accès bloque une requête, la solution la plus courte est de l'assouplir. Quand une clé n'est disponible que côté serveur, la plus courte est de la recopier côté client. Rien de malveillant : l'agent ne se pose simplement pas la question de l'utilisateur qui cherche à contourner l'appli.
S'ajoute une pile très homogène. Une grande partie de ces applis associent un front React ou Next.js, Supabase ou Firebase pour la base et l'authentification, un hébergement serverless et quelques API tierces. Les mêmes réglages par défaut produisent les mêmes failles, ce qui les rend faciles à trouver en masse. En 2025, Escape a ainsi analysé plus de 5 600 applis vibe codées publiées et rapporté plus de 2 000 vulnérabilités, plus de 400 secrets exposés et 175 cas de données personnelles accessibles. En février 2026, The Register a relayé le cas d'une appli hébergée par Lovable qui, selon le chercheur qui l'a analysée, exposait les données d'environ 18 000 utilisateurs.
Les 7 failles que l'on retrouve le plus
1. Une base de données ouverte à tous
Avec Supabase, le navigateur parle directement à la base avec une clé publique, dite anon. Cette clé est faite pour être visible : la sécurité repose entièrement sur les politiques Row Level Security (RLS) de chaque table. Une table sans RLS, ou avec une politique qui autorise tout le monde, est lisible et souvent modifiable par n'importe qui possède l'URL du projet et la clé anon, deux informations présentes dans le code du site. Firebase connaît le même problème avec des règles laissées en mode test. Le stockage de fichiers (buckets) se configure à part et s'oublie encore plus souvent.
2. Une clé secrète dans le code client
La clé service_role de Supabase contourne toutes les règles RLS. Une clé OpenAI, Anthropic ou Stripe donne accès à votre compte et à votre facture. Quand l'agent n'arrive pas à faire fonctionner un appel depuis le serveur, il arrive qu'il place la clé dans une variable exposée au navigateur, par exemple préfixée NEXT_PUBLIC_ ou VITE_. Elle se retrouve alors dans les fichiers JavaScript téléchargés par chaque visiteur. Une clé passée une fois dans l'historique Git est à considérer comme compromise, même supprimée ensuite.
3. L'accès aux données d'un autre utilisateur
La route qui renvoie une facture vérifie que l'utilisateur est connecté, mais pas que la facture lui appartient. Changer l'identifiant dans l'URL ou dans la requête suffit à lire celle d'un autre client. C'est une IDOR, la faille la plus fréquente des applications web, et la plus grave dans une appli qui sert plusieurs entreprises clientes. Notre fiche IDOR détaille les variantes et la correction.
4. Des contrôles faits seulement dans l'interface
L'agent masque le bouton « Supprimer l'utilisateur » pour les non-admins, et considère le travail fait. La route serveur qui exécute la suppression, elle, ne vérifie pas le rôle. Un utilisateur simple qui appelle cette route directement obtient les droits d'administration. Toute décision d'autorisation doit être prise côté serveur ou dans la base, jamais seulement dans ce que le navigateur affiche.
5. Des fonctions serveur sans authentification
Edge functions, routes d'API, server actions : chaque point d'entrée créé par l'agent est accessible depuis Internet, même s'il n'est appelé que par un écran précis. Les fonctions écrites pour un test, un import ponctuel ou un outil d'administration restent souvent en ligne sans contrôle de session. Elles sont les premières que cherche un attaquant.
6. Des webhooks de paiement non signés
Le webhook qui reçoit « paiement réussi » de Stripe, Lemon Squeezy ou Paddle active l'abonnement. S'il ne vérifie pas la signature envoyée par le fournisseur, n'importe qui peut lui envoyer un faux événement et débloquer l'offre payante. L'agent écrit souvent la vérification puis la commente pendant le débogage local, et elle part en production dans cet état.
7. Des dépendances inventées ou abandonnées
Un modèle peut suggérer un paquet qui n'existe pas, avec un nom plausible. Un attaquant qui enregistre ce nom sur npm ou PyPI voit son code installé par tous ceux qui suivent la même suggestion : c'est ce qu'on appelle le slopsquatting. Plus banal, l'agent ajoute des bibliothèques pour une fonction ponctuelle, puis personne ne les met à jour.
Si votre appli embarque elle-même un chatbot ou un agent, une huitième famille s'ajoute : prompt injection, fuite de données par le modèle, outils trop permissifs. Elle se teste avec l'OWASP LLM Top 10.
Vérifier votre appli vous-même en une heure
Ces vérifications se font sur votre propre appli, idéalement en préproduction, avec deux comptes de test créés pour l'occasion. Elles ne remplacent pas un test d'intrusion, mais elles attrapent les failles les plus grossières.
| Faille | Comment la vérifier | Gravité habituelle |
|---|---|---|
| Base de données ouverte | Depuis une session non connectée, interrogez l’API de votre base avec la clé publique de l’appli : une table qui répond est une table ouverte. | Critique |
| Clé secrète côté client | Cherchez « service_role », « sk_live », « sk- » dans les fichiers JavaScript servis au navigateur et dans l’historique du dépôt. | Critique |
| Données d’un autre utilisateur | Avec deux comptes de test, ouvrez une ressource du compte A, puis rejouez la requête connecté en B. | Élevée |
| Contrôle seulement dans l’interface | Connecté en utilisateur simple, appelez directement la route d’une action réservée à l’admin. | Élevée |
| Fonction serveur sans authentification | Listez les fonctions serveur et routes d’API, puis appelez chacune sans être connecté. | Élevée |
| Webhook de paiement non signé | Vérifiez dans le code que la signature du fournisseur est contrôlée avant toute mise à jour de l’abonnement. | Élevée |
| Dépendance inventée | Pour chaque paquet du fichier de dépendances, vérifiez qu’il existe, qu’il est maintenu et qu’il est réellement utilisé. | Variable |
Empêcher votre IA de réintroduire les failles
Corriger une faille ne suffit pas : au prochain prompt, l'agent peut recréer une table sans RLS ou reposer une clé côté client. La parade est de lui donner des règles permanentes, lues à chaque session. Claude Code lit le fichier CLAUDE.md, Codex et plusieurs autres agents lisent AGENTS.md, Cursor ses propres fichiers de règles. Un bloc de départ à adapter :
## Règles de sécurité (à respecter à chaque modification)
- Aucune clé secrète dans le code exécuté par le navigateur.
Seule la clé publique (anon) peut y figurer.
- Toute nouvelle table est créée avec RLS activé et une politique
qui limite chaque ligne à son propriétaire ou à son organisation.
- Tout contrôle de rôle ou de propriété est fait côté serveur,
jamais seulement en masquant un bouton.
- Toute route d'API et toute fonction serveur vérifie la session
avant de lire ou d'écrire une donnée.
- Les webhooks vérifient la signature du fournisseur avant tout traitement.
- Ne jamais désactiver une règle de sécurité pour faire passer un test.
Signaler le blocage à la place.
- N'ajouter une dépendance qu'après avoir vérifié qu'elle existe
et qu'elle est maintenue.Ces règles réduisent les régressions ; elles ne remplacent pas une vérification. Demander à l'agent de relire son propre code est utile pour les motifs connus, mais il tend à valider ce qu'il vient d'écrire, et il ignore vos règles métier : qui a le droit de voir quoi, et dans quelles conditions.
Quand faire auditer une appli vibe codée
Le bon moment est juste avant que des données réelles n'entrent dans l'appli :
- avant les premiers clients payants, surtout si l'appli sert plusieurs entreprises ;
- avant de traiter des données sensibles : santé, finances, documents d'identité, données d'enfants ;
- avant une levée de fonds ou un référencement grand compte, où l'on vous demandera une preuve de test ;
- après une refonte générée d'un bloc, quand l'agent a réécrit l'authentification ou le modèle de données.
Un audit sur un prototype qui change tous les jours rapporte peu : le constat est périmé avant d'être corrigé. Figez une version, faites-la tester, corrigez, puis faites retester. La lecture du code suit la même méthode qu'un audit de code source, ciblée sur les règles d'accès, les secrets et les fonctions serveur.
Questions fréquentes sur la sécurité du vibe coding
Le vibe coding est-il dangereux pour la sécurité ?
Pas par nature, mais il déplace le risque. Un agent de code écrit vite un code qui fonctionne ; il ne se demande pas ce qu'un utilisateur malveillant ferait de chaque route. Sans relecture orientée sécurité, les mêmes failles reviennent d'une appli à l'autre : base de données ouverte, clé secrète côté client, contrôles d'accès absents côté serveur.
Peut-on demander à Claude Code ou Codex de sécuriser son appli ?
Oui, et c'est utile pour les motifs connus : clé en dur, règle d'accès désactivée, dépendance vulnérable. L'agent reste limité sur la logique métier, parce qu'il ne connaît pas vos règles : qui a le droit de voir quoi, qui peut annuler une commande, ce qu'un rôle support peut faire. Il tend aussi à valider le code qu'il vient d'écrire. Une relecture par un humain qui attaque l'appli reste nécessaire avant d'accueillir de vrais clients.
Une appli Lovable ou Bolt est-elle moins sûre qu’une appli codée à la main ?
Pas forcément, mais elle part souvent de la même pile, Supabase et un front React, avec les mêmes réglages par défaut. C'est ce qui rend les failles si répétitives d'une appli à l'autre, et si faciles à trouver pour un attaquant qui sait où chercher.
Quand faire auditer une appli vibe codée ?
Avant d'y mettre des données réelles : premiers clients payants, données de santé ou financières, levée de fonds, référencement chez un grand compte. Faire auditer une appli encore en prototype rapporte peu, car le code change trop vite ; l'attendre après un incident coûte bien plus cher.
Combien coûte un audit de sécurité d’appli vibe codée ?
Chez Laucked, l'audit vibe coding est proposé en trois formules à prix ferme : 2 500, 3 500 et 4 500 € HT selon le nombre de rôles, la présence d'un paiement et le nombre d'organisations clientes, retest inclus. Au-delà, la mission repasse sur devis comme un pentest web classique.
Références : Supabase, Row Level Security ; Firebase Security Rules ; Escape, analyse des applis vibe codées ; The Register, février 2026 ; OWASP ASVS.