Sécurité des apps créées par IA

Ce que signifie la « sécurité du vibe coding »

Les outils d'IA (Lovable, Bolt, v0, Cursor, Replit, Windsurf) génèrent des apps avec une architecture très précise : le navigateur parle directement à la base de données (Supabase, Firebase) et aux services externes (Stripe, OpenAI, Resend). Il n'y a presque aucun serveur à toi entre les deux. Ça accélère tout, 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 HTTP, la politique CORS et l'endroit où vivent tes clés, pas la propreté du code de l'interface.

Ces éléments ne sont pas bien configurés par défaut, et l'IA les configure rarement si tu ne le lui demandes pas. Son objectif est que l'app fonctionne pour la démo, et une table sans restrictions ou une clé collée dans le frontend « fonctionnent » parfaitement. Résultat : des apps qui ont l'air impeccables et qui exposent des données ou des clés à quiconque sait où regarder. Pas besoin d'être hacker, il suffit d'ouvrir les outils de développement du navigateur.

C'est pourquoi la « sécurité du vibe coding » ne veut pas dire apprendre la cryptographie ni payer un audit. Ça veut dire connaître la demi-douzaine de failles qui se répètent dans presque toutes les apps créées par IA, savoir les vérifier depuis l'extérieur et demander à la même IA de les corriger avec des instructions précises.

Pourquoi les apps créées par IA échouent de la même façon

Il y a un schéma. L'IA optimise pour que le code compile et que l'écran affiche des données, pas pour qu'un inconnu ne puisse pas les voir. Quand une requête échoue à cause des permissions, la solution la plus courte est de retirer la permission qui gêne : désactiver le Row Level Security, ajouter une règle qui autorise tout ou utiliser la clé d'administrateur. Et l'IA choisit la solution la plus courte.

La deuxième raison, c'est qu'elle copie des templates. Les variables préfixées NEXT_PUBLIC_, VITE_ ou NUXT_PUBLIC_ sont envoyées au navigateur par conception, et beaucoup d'exemples sur internet y placent des clés qui ne devraient jamais quitter le serveur. Les règles Firebase en mode test laissent n'importe qui lire et écrire pendant 30 jours, et des apps sont lancées avec ce mode encore actif. Les en-têtes de sécurité n'apparaissent dans presque aucun tutoriel, donc ils n'apparaissent pas non plus dans l'app.

La troisième, c'est que personne ne dessine le modèle de menace. Celui qui construit avec l'IA pense à l'utilisateur qu'il veut, pas au visiteur qui ouvre l'onglet Network, copie l'URL de l'API et en retire le filtre. Ce guide consiste à se mettre à la place de ce visiteur pendant dix minutes.

Les sept failles qui touchent le plus les apps créées par IA

Des clés d'API dans le navigateur. Quand tu « connectes » un service, la clé finit dans le JavaScript côté client, où elle est publique pour toujours : n'importe qui peut la lire en affichant le code source et l'utiliser à tes frais (factures OpenAI, emails envoyés depuis ton domaine, accès à tes données). Les seules clés qui peuvent aller côté client sont celles conçues pour ça, comme la clé anon ou publishable de Supabase, la clé publique de Stripe ou la configuration Firebase, et seulement si les règles derrière sont correctes.

Des règles de base de données manquantes ou faibles. Sans Row Level Security activé sur chaque table Supabase, ou avec une politique qui autorise tout, n'importe qui lit et écrit tes données sans se connecter, via la même API que ton app. Dans Firebase, les règles en mode test ou avec allow read, write: if true font pareil. C'est la faille la plus grave et la plus fréquente, et elle est à l'origine de la vulnérabilité CVE-2025-48757 qui a exposé des données d'utilisateurs dans des apps faites avec Lovable.

Un CORS permissif. Une API qui répond avec Access-Control-Allow-Origin en reflétant n'importe quelle origine et qui autorise en plus les identifiants laisse un site malveillant faire des requêtes au nom de tes utilisateurs et lire les réponses. Le joker sur une API publique sans cookies est acceptable ; refléter l'origine avec des identifiants, jamais.

Des en-têtes de sécurité absents. Sans Content-Security-Policy, Strict-Transport-Security, X-Frame-Options (ou frame-ancestors), X-Content-Type-Options, Referrer-Policy et Permissions-Policy, ton app est exposée au clickjacking, à l'injection de scripts, au downgrade vers HTTP et aux fuites d'URL internes. Ils se configurent sur le serveur ou chez l'hébergeur (Vercel, Netlify, Cloudflare) en dix lignes.

Des fichiers sensibles accessibles. Un .env publié par erreur, un dossier .git exposé, des source maps qui permettent de reconstruire tout le code source, des sauvegardes de la base de données ou des panneaux d'administration sans authentification. Ils sont faciles à trouver parce que les attaquants les cherchent automatiquement sur chaque nouveau domaine qui apparaît.

Des sessions et des cookies mal configurés. Des cookies de session sans les attributs Secure, HttpOnly et SameSite, des tokens stockés dans le localStorage à portée de n'importe quel script, ou des sessions qui n'expirent jamais. Un petit XSS devient un vol de compte quand le cookie est lisible depuis JavaScript.

Des endpoints qui font confiance au client. Des routes d'API qui acceptent l'identifiant de l'utilisateur, le prix ou le rôle depuis le corps de la requête sans le vérifier côté serveur. Si l'interface cache le bouton d'administrateur mais que la route répond toujours à n'importe qui, le bouton ne protège rien.

Quoi vérifier selon ta stack

Lovable, Bolt ou v0 avec Supabase. Vérifie que toutes les tables ont le RLS activé et des politiques par opération (select, insert, update, delete) basées sur auth.uid() ; que la clé service_role n'est dans aucune variable publique ; que les buckets privés du Storage ont des politiques ; et que les vues et fonctions RPC ne contournent pas les politiques. Le tableau de bord Supabase inclut un Security Advisor qui liste le plus grave.

Cursor, Windsurf ou Replit avec Next.js, Nuxt ou Express déployé sur Vercel. Vérifie quelles variables d'environnement portent un préfixe public, que les routes d'API valident la session à chaque requête et pas seulement dans l'interface, que les en-têtes de sécurité sont définis (vercel.json, next.config ou nuxt.config) et que les source maps ne sont pas publiées en production.

Firebase. Remplace les règles du mode test par des règles basées sur request.auth, dans Firestore comme dans le Storage ; active App Check pour que seule ton app puisse utiliser tes services ; et vérifie que les Cloud Functions qui font quelque chose de sensible contrôlent le token de l'utilisateur avant d'agir.

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 depuis la console du navigateur ou avec curl. La vraie sécurité vit 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é.

Le cadenas HTTPS au vert ne suffit pas non plus. HTTPS chiffre le chemin entre le navigateur et ton serveur ; il ne dit rien sur le fait que le serveur donne des données à qui il ne devrait pas. Une app avec un certificat parfait et une table sans RLS est une app avec une fuite parfaitement chiffrée.

Comment le vérifier toi-même en dix minutes

Un : ouvre ton site et affiche le code source (clic droit, afficher le code source de la page). Cherche key, secret, sk_, service_role et les noms des services que tu utilises. Tout ce qui apparaît là est public.

Deux : avec l'app ouverte, va dans l'onglet Network des outils de développement, repère une requête vers ta base de données ou ton API, copie l'URL et ouvre-la dans une fenêtre de navigation privée. Si elle renvoie des données sans session, cet endpoint est ouvert. Connecté, retire le filtre utilisateur de l'URL : si elle renvoie les lignes des autres, les politiques sont mauvaises.

Trois : demande les en-têtes de ton domaine avec curl -I https://tondomaine.com et vérifie si Content-Security-Policy, Strict-Transport-Security et X-Frame-Options ou frame-ancestors apparaissent. S'il en manque un, il n'est pas configuré.

Quatre : essaie d'ouvrir /.env, /.git/config, /config.json et un fichier .js.map de ton bundle. Tous doivent renvoyer 404 ou 403.

Cinq : crée deux comptes de test et vérifie qu'aucun ne voit, ne modifie ni ne supprime ce qui appartient à l'autre, fichiers envoyés compris. C'est le test le plus ennuyeux et celui qui trouve le plus de failles.

Comment le vérifier en 30 secondes

Scanaris automatise ces tests et quelques autres. Il analyse ton site déjà publié en lecture seule : il ne touche pas à ton code, n'injecte rien et n'essaie d'exploiter rien ; il regarde ce qui est déjà public, comme n'importe qui le ferait depuis l'extérieur. Il vérifie les en-têtes, les cookies, le certificat TLS, le CORS, les secrets dans le JavaScript, les fichiers sensibles, les technologies aux versions connues, les règles Supabase si tu lui donnes une connexion en lecture seule, et aussi comment Google te voit et comment les IA te lisent.

Chaque résultat arrive classé par impact (le critique d'abord), expliqué en langage normal et avec un prompt de correction prêt à coller dans Lovable, Cursor ou l'outil que tu utilises. Colle ton URL, attends une demi-minute et tu sauras si tu peux partager ton app l'esprit tranquille.

Quoi surveiller après le lancement

La sécurité n'est pas un état, c'est une habitude. Chaque nouvelle table naît sans RLS, chaque nouvelle fonction peut mettre une clé au mauvais endroit et chaque dépendance vieillit. Programme un re-scan périodique et regarde les différences, pas tout le rapport : ce qui compte, c'est ce qui s'est ouvert depuis la dernière fois.

Surveille aussi ce qui ne dépend pas du code : que le certificat et le domaine n'expirent pas, que le site réponde, et qu'aucun script que tu n'as pas mis n'apparaisse dans le navigateur de tes utilisateurs. Et quand tu corriges quelque chose, revérifie depuis l'extérieur : la correction compte quand le scanner ne la voit plus, pas quand l'IA dit que c'est fait.

Va plus loin selon ta stack

Vérifications de sécurité clés

Guides associés

Questions fréquentes