Sécurité d'une app vibe-codée : 7 erreurs à corriger avant de publier

Ton application marche. Le formulaire enregistre, la page affiche, le bouton exporte. Ça ne veut pas dire qu’elle est sûre. Une IA de code répond à ce que tu lui demandes, pas à « fais en sorte que personne d’autre ne puisse lire les données des autres utilisateurs » si tu ne le précises jamais. Voici les sept erreurs qui reviennent le plus souvent dans les applications vibe-codées, avec le correctif pour chacune.

Pourquoi ça ne peut pas attendre

Fin septembre 2026, une enquête a recensé environ 16 000 bases de données Supabase laissant filtrer des données personnelles (noms, adresses, mots de passe) à cause d’applications mal configurées. Quelques mois plus tôt, un chercheur avait déjà documenté la faille CVE-2025-48757 : plus de 170 applications construites avec l’outil Lovable exposaient l’intégralité de leur base à n’importe qui, sans même se connecter, à cause d’un seul réglage manquant. Ce ne sont pas des cas isolés : ce sont des erreurs de configuration qui reviennent, parce que les mêmes outils d’IA scaffoldent les projets de la même façon.

Ces sept familles de failles sont si fréquentes qu’elles correspondent, une par une, à des catégories du Top 10 OWASP 2025, la référence mondiale des risques de sécurité web, mise à jour en 2025 avec deux nouvelles catégories (dont une consacrée directement aux dépendances logicielles).

Pourquoi un projet étudiant est autant concerné qu’une startup

Tu pourrais penser que ces sept erreurs concernent surtout des entreprises qui gèrent des milliers de clients. En réalité, un projet étudiant coche souvent toutes les cases qui l’exposent : un dépôt GitHub public pour montrer ton travail dans un portfolio, un lien partagé largement sur un Discord d’école ou un groupe de promo, une démonstration présentée pendant un hackathon. Rien de tout ça n’est un problème en soi, mais ça veut dire que ton projet peut être consulté, testé et parfois attaqué par bien plus de monde que les quelques camarades à qui tu penses au moment de le publier. Les correctifs ci-dessous ne demandent pas plus de compétences que le reste du projet : ils demandent juste de s’en occuper avant de partager le lien, pas après.

Les 7 erreurs, et leur correctif

1. Clé API secrète exposée côté navigateur. Une clé destinée à rester secrète (base de données, service payant, IA) se retrouve écrite en clair dans le code JavaScript envoyé au navigateur. N’importe qui peut l’extraire en trois clics avec les outils de développement. Correctif : une clé secrète ne doit jamais quitter ton serveur. Distingue toujours une clé publique (« anon » ou « publishable », prévue pour être visible) d’une clé secrète (« service_role » ou « secret », qui doit rester côté serveur uniquement, dans une fonction backend).

2. Fichier .env commité dans Git. Le fichier qui contient tes clés part avec le reste du code au premier git push, souvent sur un dépôt public. Le rapport 2025 de GitGuardian sur la fuite de secrets a recensé plus de 23,8 millions de nouveaux secrets exposés sur GitHub public en 2024, soit 25 % de plus que l’année précédente. Correctif : ajoute .env à ton fichier .gitignore avant le premier commit, jamais après. Si un secret a déjà été poussé, considère-le comme compromis et régénère-le : le retirer de l’historique ne suffit pas, il faut le changer.

3. Base de données sans Row Level Security (RLS). Sur Supabase (la base de données la plus utilisée par les outils de vibe-coding), la documentation officielle est sans détour : « une table dans un schéma exposé, sans RLS, est lisible et modifiable par n’importe quel rôle ayant un droit d’accès dessus. » C’est exactement la cause de la faille CVE-2025-48757 : Supabase désactive la RLS par défaut sur chaque nouvelle table, et le code généré par l’outil ne l’activait jamais. Correctif : active la RLS sur chaque table (alter table nom_table enable row level security;) et écris une politique par opération, par exemple pour qu’un utilisateur ne voie que ses propres lignes :

create policy "Chacun voit ses propres données"
on ma_table for select
to authenticated
using ( (select auth.uid()) = user_id );

4. Authentification « maison ». Réécrire soi-même la gestion des mots de passe, des sessions ou des tokens, plutôt que d’utiliser un système éprouvé. C’est la catégorie « Authentication Failures » du Top 10 OWASP 2025. Correctif : utilise le système d’authentification déjà fourni par ta plateforme (Supabase Auth ou équivalent) plutôt que d’inventer le tien. Ce n’est presque jamais plus rapide de le faire soi-même, et c’est beaucoup plus risqué.

5. Absence de validation des entrées. Faire confiance à ce qu’un formulaire ou une requête envoie, sans jamais vérifier le format, la taille ou le contenu. C’est la catégorie « Injection » du Top 10 OWASP 2025, historiquement l’une des plus exploitées. Correctif : valide et nettoie chaque entrée côté serveur (pas seulement côté navigateur, qui peut être contourné), et utilise des requêtes préparées plutôt que d’assembler du texte SQL à la main.

6. CORS grand ouvert. Une API configurée pour répondre à n’importe quel site web (Access-Control-Allow-Origin: *), ce qui permet à un site malveillant d’appeler ton API au nom d’un utilisateur connecté. C’est un exemple classique de la catégorie « Security Misconfiguration » du Top 10 OWASP 2025. Correctif : autorise explicitement une liste précise de domaines de confiance, et ne renvoie jamais l’en-tête Origin du visiteur tel quel dans ta réponse.

7. Dépendances vulnérables. Installer des paquets sans jamais vérifier s’ils contiennent des failles connues. Le Top 10 OWASP 2025 a créé une catégorie dédiée, « Software Supply Chain Failures », qui élargit l’ancienne catégorie « composants vulnérables et obsolètes » de 2021, signe que le sujet est jugé encore plus critique qu’avant. Correctif : lance npm audit (ou l’équivalent de ton langage), qui « soumet une description des dépendances de ton projet à ton registre par défaut et demande un rapport des failles connues », d’après la documentation officielle de npm. Garde un fichier de verrouillage (package-lock.json) et mets à jour régulièrement.

Une checklist avant de publier

Avant de partager le lien de ton projet, vérifie dans l’ordre :

• Aucune clé secrète ne figure dans le code envoyé au navigateur (inspecte le code source affiché par ton navigateur, pas seulement tes fichiers).
• .env figure dans .gitignore, et aucun secret ne traîne dans l’historique Git.
• La RLS est activée sur chaque table de ta base, avec au moins une politique testée.
• Tu utilises un système d’authentification existant, pas le tien.
• Chaque formulaire et chaque route d’API valide ses entrées côté serveur.
• Ton API n’autorise que les domaines dont tu as vraiment besoin.
• npm audit (ou équivalent) ne remonte aucune faille critique non corrigée.
• Aucun secret n’apparaît dans l’historique Git de ton dépôt, même dans un commit ancien que tu penses avoir « corrigé » depuis.
• Tu as testé l’application avec un second compte pour vérifier qu’il ne voit jamais les données du premier.

À retenir

• Une app qui « marche » à l’écran peut quand même exposer les données de tous ses utilisateurs : le test visuel ne suffit pas.
• Les sept erreurs les plus fréquentes correspondent chacune à une catégorie reconnue du Top 10 OWASP 2025.
• La faille la plus documentée dans les outils de vibe-coding est l’absence de Row Level Security sur Supabase : active-la systématiquement, sur chaque table.
• Une clé secrète qui a été committée ou envoyée au navigateur doit être régénérée, pas seulement supprimée.
• Si ton projet manipule des données personnelles réelles (même celles de camarades de classe), traite-le avec le même sérieux qu’un projet professionnel.

Pour une vérification guidée de ces sept points sur ton propre projet, la skill securite-app-vibe reprend cette checklist pas à pas.