Checklist gratuite · sans inscription
La checklist de sécurité du vibe coder.
Les outils de création par IA produisent des applications qui paraissent terminées, et les failles de sécurité se voient rarement à l’écran. Voici 15 contrôles sur les problèmes les plus fréquents dans les applications générées par IA, chacun accompagné d’un test que vous pouvez réaliser vous-même. Beaucoup touchent aux risques du OWASP Top 10. Commencez par les points de gravité élevée .
- 01Élevée
Clés API secrètes dans le code front-end
Contrôle : Ouvrez les outils de développement de votre navigateur (onglets Sources et Network) et recherchez « key », « token » et « secret ». Les clés publiables, comme la clé publique (anon) de Supabase ou la clé publiable de Stripe, sont conçues pour être publiques. Les clés secrètes, les clés service-role et les clés d’API tierces (une clé OpenAI, par exemple) ne le sont pas. Si vous en trouvez une, déplacez cet appel côté serveur et renouvelez la clé.
- 02Élevée
Connexion contrôlée uniquement dans le navigateur
Contrôle : Copiez l’URL d’une page réservée aux utilisateurs connectés et ouvrez-la dans une fenêtre privée, ou appelez l’API qu’elle utilise sans session. Si les données reviennent quand même, le contrôle de connexion se trouve dans l’interface et le serveur ne l’applique pas.
- 03Élevée
Pas de sécurité par ligne ni de règles d’accès par utilisateur
Contrôle : Connecté en tant qu’utilisateur A, remplacez un identifiant dans une requête (ou dans l’URL) par celui de l’utilisateur B. Si les données de B reviennent, l’accès n’est pas appliqué là où les données se trouvent.
- 04Élevée
Tables de base de données accessibles depuis le navigateur sans règles d’accès
Contrôle : Si le navigateur interroge directement votre base de données (fréquent avec Supabase), ce n’est sûr que si la sécurité par ligne (row-level security) est activée sur chaque table exposée, avec des politiques conformes à vos règles. Vérifiez chaque table dans le tableau de bord de votre base. Une table sans sécurité par ligne peut être lue ou modifiée par toute personne détenant la clé publique.
- 05Élevée
Aucune validation des saisies côté serveur
Contrôle : Envoyez des données inattendues directement à l’API plutôt que par le formulaire : texte très long, balises script, types de données incorrects, quantités négatives. Si le serveur les accepte, ajoutez une validation côté serveur ; les contrôles du formulaire seul peuvent être contournés.
- 06Élevée
Secrets enregistrés dans le dépôt de code
Contrôle : Recherchez dans le dépôt et son historique les clés, mots de passe et valeurs .env. Tout ce que vous trouvez doit être renouvelé (le supprimer de la dernière version ne suffit pas) puis déplacé dans des variables d’environnement ou dans le coffre à secrets de votre hébergeur.
- 07Moyenne
Aucune limitation du nombre de requêtes
Contrôle : Sur votre propre application, appelez plusieurs fois de suite, très rapidement, une connexion, une inscription ou un point d’accès fonctionnant avec l’IA. Si rien ne vous ralentit, vous êtes exposé aux tentatives de devinette de mots de passe, aux inscriptions indésirables et aux factures d’utilisation inattendues.
- 08Moyenne
CORS trop permissif
Contrôle : Vérifiez de quels sites web votre API accepte les requêtes issues d’un navigateur. Un joker (*) est acceptable pour des données réellement publiques ; pour tout ce qui se trouve derrière une connexion, n’autorisez que vos propres domaines.
- 09Moyenne
Pages ou requêtes qui ne passent pas par HTTPS
Contrôle : Vérifiez que chaque page se charge en HTTPS et que la console du navigateur n’affiche aucun avertissement de « contenu mixte » pour les scripts, images ou appels d’API.
- 10Moyenne
Messages d’erreur qui révèlent le fonctionnement interne
Contrôle : Provoquez une erreur, par exemple en envoyant un formulaire incomplet ou en ouvrant un enregistrement inexistant. Si les utilisateurs voient des traces d’exécution, des requêtes de base de données ou des chemins de fichiers, consignez le détail en privé et affichez à la place un message simple.
- 11Élevée
Points d’accès d’administration ou internes non protégés
Contrôle : Listez chaque page d’administration, chaque route d’API interne et chaque tâche planifiée. Chacune doit exiger un utilisateur connecté disposant du bon rôle. Une URL difficile à deviner n’est pas une protection.
- 12Élevée
Mots de passe mal gérés
Contrôle : Les mots de passe doivent être hachés par un service ou une bibliothèque d’authentification éprouvés, jamais stockés en clair ni écrits dans les journaux. Si l’outil d’IA a écrit son propre système de connexion, remplacez-le par un fournisseur d’authentification géré.
- 13Moyenne
Dépendances non examinées
Contrôle : Lancez l’audit de votre gestionnaire de paquets (npm audit, par exemple) pour repérer les vulnérabilités connues, mettez à jour ce qu’il signale et supprimez les paquets que l’application n’utilise plus.
- 14Moyenne
Téléversements de fichiers sans restriction
Contrôle : Si les utilisateurs peuvent téléverser des fichiers, vérifiez que le type et la taille sont limités côté serveur, que les fichiers téléversés ne peuvent pas s’exécuter comme du code et que les fichiers privés ne sont pas accessibles à une URL publique ou devinable.
- 15Élevée
Ni sauvegardes ni plan de reprise
Contrôle : Vérifiez que la base de données est sauvegardée automatiquement, jusqu’à quelle date vous pouvez restaurer, et faites un test de restauration. Une sauvegarde que personne n’a restaurée est une hypothèse, pas un plan.
FAQ
Questions fréquentes
Le vibe coding est-il sûr ?
Pour des prototypes, oui. Dès qu’une application contient de vraies données clients ou encaisse des paiements, elle exige les mêmes contrôles de sécurité que n’importe quel autre logiciel, et les applications créées avec l’IA en sautent souvent certains : clés secrètes laissées dans le code du navigateur, contrôles de connexion présents seulement dans l’interface, tables de base de données sans règles d’accès, saisies que le serveur ne valide jamais. L’application peut sembler terminée alors que ces failles existent. Cette checklist vous aide à les repérer avant que vos clients ne s’appuient sur l’application.
Quels sont les problèmes de sécurité les plus courants dans les applications générées par IA ?
Ceux que nous rencontrons le plus souvent sont des clés secrètes exposées dans le code front-end, une connexion appliquée seulement dans le navigateur, l’absence de sécurité par ligne (un utilisateur peut alors lire les données d’un autre) et l’absence de validation côté serveur. Plusieurs relèvent de catégories de l’OWASP Top 10 (édition 2025), la liste de référence des risques de sécurité des applications web, comme Broken Access Control et Authentication Failures. Tous sont corrigeables.
Comment sécuriser une application créée avec Lovable, Bolt ou Replit ?
Traitez d’abord les points de gravité élevée : déplacez les clés secrètes côté serveur, appliquez la connexion et les règles d’accès côté serveur ou dans la base de données, activez la sécurité par ligne sur chaque table exposée et validez les saisies côté serveur. Passez ensuite aux points de gravité moyenne. Si vous préférez que des ingénieurs s’en chargent, nous pouvons examiner l’application et vous dire ce qu’il faut corriger.
Des points dont vous ne savez pas comment les corriger ?
Envoyez-nous l’application ou le dépôt. Nous l’examinerons, nous vous dirons quels problèmes sont réels et lesquels sont acceptables en l’état, et quel travail représentent les corrections.