18 octobre 2026 · 9 min de lecture
Les 10 failles de sécurité les plus fréquentes dans une application générée par IA
Dans les applications générées par IA, les failles viennent presque toujours des mêmes endroits : contrôle d’accès manquant, base de données ouverte, clés secrètes dans le navigateur, authentification fragile, entrées non validées, dépendances douteuses et fonctions IA trop permissives. Chacune se teste en quelques minutes et se corrige, une fois repérée.
Les études publiques sont cohérentes : le code produit par les assistants IA fonctionne bien plus souvent qu’il n’est sûr. Le rapport GenAI Code Security de Veracode relève qu’environ 45 % des échantillons testés échouent à des contrôles tirés de l’OWASP Top 10 ; le benchmark SusVibes de Carnegie Mellon observe un écart plus net encore entre code correct et code sûr. Les méthodes diffèrent : ne comparez pas ces chiffres, retenez la direction.
Voici les dix familles de failles que nous cherchons en priorité dans une application créée avec Lovable, Bolt, Replit, Cursor ou Claude Code. Pour chacune : à quoi ça ressemble, comment le vérifier et comment le corriger.
Les dix failles
1. Contrôle d’accès cassé (IDOR)
L’application vérifie que vous êtes connecté, pas que la donnée est la vôtre. Test : connectez-vous avec deux comptes, copiez l’identifiant d’une facture du compte A et ouvrez-la avec le compte B. Correctif : vérifier la propriété de chaque ressource côté serveur, à chaque requête.
2. Base de données sans règles d’accès
Avec Supabase, une table sans Row Level Security est lisible et modifiable avec la clé publique. Test : appeler l’API de la table avec uniquement la clé publique. Correctif : activer RLS sur chaque table et écrire des politiques minimales (voir notre guide dédié).
3. Secrets dans le navigateur
Clés de paiement, d’IA ou d’administration dans le code envoyé aux visiteurs — souvent à cause d’une variable préfixée NEXT_PUBLIC_ ou VITE_, qui est volontairement publiée. Correctif : déplacer l’appel côté serveur, révoquer la clé exposée.
4. Clé administrateur utilisée côté client
La clé « service_role » de Supabase contourne toute la sécurité de la base. Elle ne doit jamais quitter un serveur. Correctif : l’utiliser uniquement dans des fonctions serveur et la renouveler si elle a été publiée.
5. Authentification fragile
Réinitialisation de mot de passe prévisible, absence de limitation des tentatives, sessions qui n’expirent jamais, rôle administrateur déterminé par un champ modifiable par l’utilisateur. Correctif : limitation de débit, jetons à usage unique, rôles stockés côté serveur.
6. Entrées non validées
Formulaires et paramètres acceptés tels quels : injection SQL ou NoSQL, XSS (script injecté dans une page vue par d’autres), traversée de chemin. Correctif : valider et typer toutes les entrées côté serveur, échapper les sorties, utiliser des requêtes paramétrées.
7. Configuration web laxiste
CORS ouvert à toutes les origines avec identifiants, cookies sans Secure/HttpOnly/SameSite, en-têtes de sécurité absents, messages d’erreur détaillés en production. Correctif : configuration minimale décrite dans notre checklist.
8. Dépendances vulnérables ou inventées
L’IA suggère parfois des paquets qui n’existent pas — un attaquant peut publier un paquet du même nom — ou des versions obsolètes. Correctif : vérifier chaque dépendance, lancer un audit des paquets, figer les versions.
9. Envois de fichiers et appels sortants non contrôlés
Upload sans contrôle de type ni de taille, fonctions qui récupèrent une URL fournie par l’utilisateur (SSRF). Correctif : liste blanche de types, stockage isolé, interdire les adresses internes.
10. Fonctions IA trop permissives
Un assistant intégré qui obéit à un texte malveillant (prompt injection) et dispose d’outils ou de données trop larges. Correctif : moindre privilège pour les outils, séparer instructions et données, valider les actions sensibles par un humain.
Comment vérifier sans être expert
- Créez deux comptes de test et essayez de lire, modifier et supprimer les données de l’un avec l’autre.
- Ouvrez l’onglet Réseau du navigateur : repérez les clés, identifiants et réponses trop bavardes.
- Cherchez vos secrets dans le code livré et dans l’historique Git.
- Lancez notre scan gratuit pour les contrôles de surface, puis faites tester la logique d’accès.
Et ensuite ?
Les points 1, 2 et 3 concentrent l’essentiel du risque. Si vous ne devez en traiter que trois, traitez ceux-là. Pour une application qui manipule des données de clients ou des paiements, un audit sur périmètre signé donne une réponse définitive et un plan de correction chiffré.
Questions fréquentes
Ces failles sont-elles propres à l’IA ?
Non : ce sont les failles classiques du classement OWASP Top 10. L’IA les reproduit parce qu’elle optimise le fonctionnement, pas la résistance à un attaquant, et parce que l’utilisateur ne relit pas le code produit.
Par quoi commencer si je n’ai qu’une heure ?
Dans l’ordre : vérifier que la base de données a des règles d’accès testées avec deux comptes, chercher des clés secrètes dans le navigateur, et vérifier côté serveur que chaque ressource appartient à l’utilisateur connecté.
Un scanner automatique suffit-il à trouver ces failles ?
Il en trouve certaines (clés exposées, en-têtes, cookies) mais pas les plus graves : un scanner ne sait pas que l’utilisateur A ne doit pas voir la facture de B. Ces tests de logique demandent deux comptes et un humain.
Contenu général, non contractuel. Un audit sur périmètre signé reste le seul moyen de prouver l’état de sécurité d’une application.
Voir l’audit de sécurité