Le vibe coding n'est pas sécurisé par défaut, et il n'est pas non plus risqué par nature : une application web générée par l'IA est aussi sûre que les vérifications dont elle a fait l'objet. Les mêmes quelques failles reviennent dans les applications créées avec des créateurs IA : des données lisibles par n'importe qui, des clés secrètes dans le navigateur, des règles appliquées seulement dans l'interface. Chacune peut être testée par un non-développeur en quelques minutes, et chacune a un prompt de suite qui la corrige.
Cette checklist s'adresse aux fondateurs, aux freelances et aux petites équipes sur le point de donner accès à un premier vrai utilisateur à une application créée avec un créateur IA. Si la méthode est nouvelle pour vous, commencez par notre guide du vibe coding. Si votre application utilise Supabase, le détail du côté base de données se trouve dans notre guide sur la sécurité au niveau des lignes de Supabase (RLS).
Pourquoi les applications créées avec l'IA échouent de la même façon
Un créateur IA optimise pour obtenir une application qui fonctionne à l'écran, et un écran qui fonctionne ne dit rien de qui d'autre peut atteindre les données qui se trouvent derrière. Quand vous demandez « un tableau de bord où chaque client voit ses factures », le modèle construit d'abord l'écran. Que la base de données refuse de renvoyer les factures des autres clients est un travail distinct, qui n'est fait que si le prompt ou les réglages par défaut du créateur l'exigent.
Un exemple public montre la forme du problème. En 2025, une fiche de vulnérabilité (CVE-2025-48757) a été publiée, décrivant des politiques de sécurité au niveau des lignes insuffisantes dans des sites générés avec Lovable, jusqu'au 2025-04-15, qui permettaient à des visiteurs non authentifiés de lire ou d'écrire dans des tables. L'entrée de la National Vulnerability Database précise aussi que l'éditeur conteste ce constat et indique que chaque client est responsable de la protection des données de sa propre application. Les deux affirmations mènent à la même conclusion pratique : celui qui publie l'application doit vérifier ses règles d'accès, quel que soit l'outil qui l'a écrite.
Les sept failles en un coup d'œil
La plupart de ces failles correspondent au Top 10 OWASP, la liste de référence des risques des applications web, dans son édition 2025. Le tableau ci-dessous reprend les noms de catégories de cette liste.
| Faille | Ce que fait un attaquant | Catégorie OWASP 2025 | Votre test de 10 minutes |
|---|---|---|---|
| 1. Sécurité au niveau des lignes absente | Lit ou modifie n'importe quelle table via l'API publique | A01 Broken Access Control | Deux comptes, comparez ce que chacun voit |
| 2. Clés secrètes dans le frontend | Copie la clé depuis le navigateur et dépense votre argent | A02 Security Misconfiguration | Onglet Réseau et code source de la page |
| 3. Règles uniquement dans l'interface | Appelle directement l'API et ignore le bouton masqué | A01 Broken Access Control | Rejouez une requête avec le mauvais rôle |
| 4. Pages d'administration accessibles par URL | Tape /admin dans la barre d'adresse | A01 Broken Access Control | Ouvrez les URL d'administration déconnecté, puis en utilisateur normal |
| 5. Envois de fichiers non validés | Envoie des fichiers énormes, inadaptés ou publics | A06 Insecure Design | Envoyez un mauvais fichier, ouvrez son lien déconnecté |
| 6. Dépendances obsolètes | Exploite une faille connue d'un ancien paquet | A03 Software Supply Chain Failures | Lancez la commande d'audit des paquets |
| 7. Aucune limite de débit | Inonde l'inscription ou vide vos crédits IA | A06 Insecure Design | Répétez une requête 50 fois et observez |
1. Sécurité au niveau des lignes absente
Avec un backend Supabase, le navigateur parle à la base de données par une API publique : la seule chose qui sépare un visiteur de vos tables est la sécurité au niveau des lignes (row level security, RLS), des règles attachées à chaque table qui disent quelles lignes un utilisateur peut lire ou écrire. Une table sans RLS activée peut être lue par quiconque possède la clé publique, et cette clé est dans le navigateur par conception. Supabase explique le mécanisme dans sa documentation sur la sécurité au niveau des lignes.
Le test prend cinq minutes. Créez deux comptes, A et B, avec des e-mails différents. Avec A, créez un enregistrement (une facture, une note, un projet). Déconnectez-vous, connectez-vous avec B, et cherchez l'enregistrement de A dans chaque liste et chaque recherche. Ouvrez ensuite les outils de développement du navigateur, allez dans l'onglet Réseau, rechargez la page, cliquez sur une requête vers la base de données et lisez la réponse : elle ne doit contenir que les lignes de B. Enfin, déconnectez-vous et rechargez la même page : les requêtes doivent ne rien renvoyer, ou renvoyer une erreur.
Prompt de suite : « Liste chaque table de la base de données en indiquant si la sécurité au niveau des lignes est activée et quelles politiques s'appliquent. Active la RLS sur chaque table qui n'en a pas, et écris des politiques pour qu'un utilisateur ne puisse lire, insérer, modifier et supprimer que les lignes dont user_id est égal à son propre identifiant. Montre-moi les politiques et explique toute table que tu as laissée publique volontairement. »
2. Clés secrètes dans le frontend
Tout ce qui est envoyé au navigateur est public, y compris chaque clé que l'on peut trouver dans le code source de la page. Certaines clés sont faites pour être publiques (la clé publique de Supabase, protégée par la RLS). D'autres non : clés secrètes de paiement, clés de fournisseurs d'IA, clés de services d'e-mail, clé service role de la base de données. Un visiteur qui en copie une peut envoyer des e-mails en votre nom ou lancer des requêtes d'IA sur votre facture.
Pour le tester, ouvrez l'application publiée, ouvrez les outils de développement, allez dans l'onglet Réseau et dans l'onglet Sources, et cherchez les premiers caractères de chaque secret que vous utilisez (par exemple « sk_ » pour une clé de paiement) ainsi que le nom de chaque fournisseur. Cherchez aussi dans le code du projet et dans son dépôt GitHub si vous l'exportez. Un secret dans un dépôt public est considéré comme divulgué, même après suppression.
Prompt de suite : « Cherche dans tout le projet les clés d'API, jetons et secrets présents dans le code client. Déplace chaque appel qui nécessite un secret dans une fonction edge côté serveur, lis la clé depuis les variables d'environnement, et n'utilise jamais la clé service role dans le navigateur. Liste ce que tu as déplacé. » Si un secret a été exposé, renouvelez-le chez le fournisseur : supprimer le code n'annule pas la clé.
3. Autorisation vérifiée seulement dans l'interface
Masquer un bouton est un choix de design, pas une permission. Si le bouton de suppression est masqué pour un rôle « lecteur » mais que la base accepte quand même la requête de suppression, tout lecteur muni des outils de développement peut l'envoyer. Les règles doivent être appliquées là où vivent les données, l'interface ne faisant que les refléter.
Pour le tester, connectez-vous avec le rôle le plus bas, effectuez une action autorisée comme une lecture, et dans l'onglet Réseau copiez cette requête (clic droit, « Copy as fetch »). Modifiez-la pour en faire une action interdite, comme changer l'identifiant d'un autre enregistrement ou un champ de rôle, et exécutez-la dans la console. Si elle réussit, la règle n'existe que dans l'interface. Vérifiez aussi qu'un utilisateur ne peut pas modifier son propre rôle ou son propre champ de plan.
Prompt de suite : « Pour chaque rôle, liste les actions qu'il peut effectuer sur chaque table. Applique-les avec des politiques de base de données, pas seulement dans l'interface. Empêche les utilisateurs de modifier leurs propres colonnes role, plan ou user_id. »
4. Pages d'administration accessibles par URL
Une page d'administration simplement absente du menu reste accessible à quiconque devine l'adresse. La page doit vérifier le rôle avant d'afficher quoi que ce soit, et les données qui se trouvent derrière doivent être protégées par les politiques du point 1.
Pour le tester, listez vos routes d'administration (/admin, /settings/users, /dashboard/all). Ouvrez chacune dans une fenêtre privée en étant déconnecté, puis connecté en utilisateur normal. Vous devez arriver sur une page de connexion ou sur une page « accès refusé », et l'onglet Réseau ne doit montrer aucune donnée d'administration dans aucune réponse.
Prompt de suite : « Protège chaque route d'administration pour que seuls les utilisateurs ayant le rôle admin puissent l'ouvrir, redirige tous les autres, et assure-toi que les requêtes de données de ces pages échouent aussi pour les non-administrateurs. »
5. Envois de fichiers sans validation
Un champ d'envoi qui accepte n'importe quel fichier, de n'importe quelle taille, dans un dossier public, permet à des inconnus d'héberger du contenu sur votre domaine et de remplir votre stockage. Les documents privés (contrats, CV, factures) ne doivent pas être lisibles par un lien devinable.
Pour le tester, envoyez un fichier du mauvais type (un exécutable renommé en .jpg) et un fichier très volumineux. Copiez ensuite le lien d'un document privé envoyé et ouvrez-le dans une fenêtre privée. S'il s'ouvre, le bucket est public.
Prompt de suite : « Limite les envois à ces types de fichiers : [liste] et à une taille maximale de [x Mo], vérifiée à l'envoi. Rends le bucket privé, ajoute des politiques de stockage pour qu'un utilisateur ne puisse lire que ses propres fichiers, et sers les fichiers par des liens signés qui expirent. »
6. Dépendances obsolètes
Une application est faite de centaines de paquets open source, et un paquet présentant une faille connue est une porte d'entrée toute prête. OWASP range cela sous les défaillances de la chaîne d'approvisionnement logicielle. L'IA peut aussi choisir une ancienne version d'un paquet qu'elle a apprise dans d'anciens exemples.
Le test tient en une commande dans le projet exporté : « npm audit » liste les vulnérabilités connues des paquets installés. Si vous ne pouvez pas la lancer, demandez à l'IA de faire la revue équivalente. Planifiez-la de nouveau avant chaque version majeure.
Prompt de suite : « Vérifie les dépendances à la recherche de vulnérabilités connues et de versions majeures obsolètes. Mets à jour celles qui ont un correctif, évite les changements cassants, et liste ce que tu n'as pas pu mettre à jour et pourquoi. Supprime les paquets que l'application n'utilise pas. »
7. Aucune limite de débit sur l'inscription et les endpoints IA
Sans limites, un script peut créer des milliers de faux comptes ou appeler votre endpoint IA jusqu'à ce que ce soit la facture de votre fournisseur, et non le nombre de vos utilisateurs, qui grossisse. Deux endroits comptent le plus : l'inscription (et la réinitialisation du mot de passe, qui envoie des e-mails) et toute fonction qui appelle une API payante.
Pour le tester, envoyez plusieurs fois de suite la même requête d'inscription ou d'IA depuis les outils de développement ou un script simple, et regardez si quelque chose la ralentit ou la bloque. Vérifiez aussi que les endpoints IA exigent un utilisateur connecté et qu'un utilisateur ne peut pas envoyer un prompt de 10 Mo.
Prompt de suite : « Exige la connexion sur chaque fonction edge qui appelle une API payante, limite chaque utilisateur à [n] appels par heure, plafonne la taille de l'entrée, et renvoie une erreur claire quand la limite est atteinte. Active la confirmation par e-mail et un captcha à l'inscription. »
Données personnelles et RGPD
Si vos utilisateurs sont en Europe, l'application détient des données personnelles et vous en êtes responsable, quel que soit l'outil qui a créé l'application. Les failles de sécurité ci-dessus sont aussi la voie habituelle des fuites de données personnelles. Au-delà, vérifiez les bases : une politique de confidentialité conforme à ce que l'application collecte réellement, un moyen de supprimer le compte et les données d'un utilisateur, et aucune donnée personnelle dans les journaux ou les outils d'analyse que vous n'aviez pas prévu d'envoyer. Notre guide sur le RGPD et les applications no-code IA détaille davantage le volet juridique.
Prompt de suite : « Ajoute une fonction de suppression de compte qui supprime les lignes et les fichiers de l'utilisateur, liste chaque champ de données personnelles que nous stockons et pourquoi, et assure-toi qu'aucune donnée personnelle n'est écrite dans les journaux. »
Ce que Cadrant fait par défaut, et ce qu'il ne fait pas
Cadrant, notre créateur, génère des applications React avec un backend Supabase dans votre propre compte Supabase. Par défaut, l'IA écrit les migrations de base de données avec des politiques de sécurité au niveau des lignes sur les tables par utilisateur, y compris des politiques de stockage, et elle peut inspecter le schéma et les politiques actuels avant de les modifier. Les clés secrètes ne sont pas placées dans le code client : les intégrations comme Stripe, OpenAI ou les services d'e-mail passent par des fonctions edge Supabase, avec les secrets stockés en variables d'environnement. Notre documentation le décrit dans les pages fonctions edge et variables d'environnement.
Les réglages par défaut réduisent le nombre d'erreurs ; ils ne remplacent pas le test. Un prompt peut encore demander une table publique, un modèle peut encore oublier une politique sur une table que vous ajoutez plus tard, et aucun créateur ne relit vos règles métier à votre place. Lancez le test à deux comptes après chaque gros changement, quel que soit l'outil.
Une checklist avant le lancement
Quand l'application gère des paiements, des données de santé ou d'autres informations réglementées, une revue ponctuelle par un professionnel de la sécurité vaut son coût : cette checklist détecte les failles courantes, pas toutes les failles. Côté création, consultez notre page créateur d'application IA.