Sécurité des apps créées par IA
Les apps vibe-codées sortent en quelques heures, mais les bases de la sécurité —secrets exposés, règles de base de données manquantes, CORS ouvert, en-têtes absents— passent à la trappe en chemin. Ce guide explique les failles qui touchent vraiment les apps créées par IA, comment les vérifier en 30 secondes, et où aller plus loin selon ta stack.
Ce que signifie la « sécurité du vibe coding »
Les outils d'IA construisent des apps où le navigateur parle directement à ta base de données et à tes services. C'est pratique, mais ça déplace la sécurité de ton code vers ta configuration : ce qui te protège, ce sont les règles de la base de données, les en-têtes et l'endroit où vivent tes clés — pas le joli code de l'interface.
Le problème, c'est que ces éléments ne sont pas configurés correctement par défaut, et l'IA les configure rarement pour toi. Résultat : des apps qui semblent parfaites mais exposent des données ou des clés à quiconque sait où regarder.
Les failles qui touchent le plus les apps créées par IA
Clés API dans le navigateur : quand tu « connectes » un service, la clé finit dans le JavaScript côté client, où elle est publique pour toujours.
Règles de base de données manquantes ou faibles : sans Row-Level Security correct (Supabase) ou avec des règles en mode test (Firebase), n'importe qui lit et écrit dans tes tables sans se connecter.
CORS permissif : une politique qui reflète n'importe quelle origine avec des identifiants expose les données de tes utilisateurs.
En-têtes de sécurité manquants : sans CSP, HSTS ou X-Frame-Options, ton app est exposée au clickjacking, à l'injection et au downgrade.
Fichiers sensibles accessibles : .env, source maps ou sauvegardes qui permettent à n'importe qui de reconstruire ton code ou de fuiter des secrets.
Une app « qui a l'air correcte » ne veut pas dire qu'elle est sûre
Cacher un bouton dans l'interface ne protège rien : la requête reste une URL publique que n'importe qui peut appeler directement. La vraie sécurité se joue sur le serveur et dans la base de données, pas dans ce que voit l'utilisateur. C'est pourquoi vérifier depuis l'extérieur —comme le ferait un attaquant— est le seul moyen de savoir ce qui est réellement exposé.
Comment le vérifier en 30 secondes
Scanaris analyse ton site publié en lecture seule : il ne touche jamais à ton code et ne modifie rien. Il détecte ces failles, les classe par impact (les critiques d'abord) et te donne un prompt de correction IA prêt à coller pour chaque résultat. Colle ton URL et sois sûr de toi avant de partager ton app.
Va plus loin selon ta stack
Next.js
Sécurité pour ton app Next.js
Supabase
Sécurité pour ton app avec Supabase
Firebase
Sécurité pour ton app avec Firebase
Vercel
Sécurité lors du déploiement sur Vercel
Lovable
Sécurité et visibilité pour ton app Lovable
Bolt
Sécurité pour ton appli Bolt
v0
Sécurité pour ton appli v0
Replit
Sécurité pour ton appli Replit
Cursor
Sécurité pour le code que tu écris avec Cursor
Vérifications de sécurité clés
Guides associés
Questions fréquentes
Mon app Lovable, Bolt ou Cursor est-elle sécurisée ?
Elle peut l'être, mais par défaut elle sort en général avec des clés dans le frontend, des règles de base de données incomplètes et aucun en-tête de sécurité. Le seul moyen de le savoir, c'est de vérifier ton site publié : Scanaris le fait en 30 secondes, en lecture seule.
Est-ce dangereux pour mon site de le scanner ?
Non. Scanaris effectue des vérifications en lecture seule sur des informations déjà publiques (en-têtes, cookies, certificats, fichiers accessibles). Il ne modifie, ne supprime ni n'injecte jamais rien. Tu ne dois scanner que des sites qui t'appartiennent ou que tu es autorisé à tester.
Faut-il connaître la sécurité pour l'utiliser ?
Non. Chaque résultat est accompagné d'une explication claire et d'un prompt de correction IA prêt à coller, pour que tu puisses le résoudre sans être un expert.