Application créée avec l’IA : les failles de sécurité les plus fréquentes

Vous avez construit une application qui fonctionne, et c’est une vraie réussite. Mais « qui fonctionne » ne veut pas dire « qui est protégée ». Quand nous relisons des applications créées avec l’IA, nous retrouvons très souvent les mêmes failles. Elles ne demandent pas un pirate de génie pour être exploitées : un utilisateur curieux suffit parfois.

La bonne nouvelle, c’est qu’elles sont bien connues, et qu’elles se corrigent généralement sans tout reconstruire. Voici les plus fréquentes, expliquées simplement, avec pour chacune un moyen de vérifier si votre application est concernée.

Pourquoi l’IA laisse passer ces failles

Les outils d’IA construisent ce que vous leur demandez, et ils le font bien. Mais la sécurité, c’est surtout ce que l’on n’a pas demandé : empêcher un utilisateur de voir ce qui ne le regarde pas, refuser une action interdite, cacher ce qui doit rester secret. Si ces règles ne figurent pas dans votre description, l’IA ne les invente pas toujours.

S’y ajoute un effet d’accumulation. Au fil des demandes, l’IA modifie des morceaux de l’application sans toujours avoir la vue d’ensemble. Une règle de sécurité ajoutée au début peut être affaiblie plus tard, par une correction qui n’avait rien à voir. C’est pour cela que nous recommandons de bien décrire les droits d’accès dès le départ, puis de les vérifier régulièrement.

1. Des droits d’accès mal configurés

C’est de loin la faille la plus fréquente. L’application affiche à chaque utilisateur ses propres informations, mais rien n’empêche réellement d’accéder à celles des autres. Il suffit parfois de modifier un numéro dans l’adresse de la page, ou d’appeler directement la base de données, pour lire les devis, les factures ou les coordonnées de tous les clients.

Dans beaucoup d’applications construites avec Supabase, cette protection repose sur des règles appelées « Row Level Security ». Si elles sont désactivées ou trop permissives, la base de données répond à n’importe qui. Supabase signale d’ailleurs ce problème dans son tableau de bord : un avertissement à ne pas ignorer.

2. Des vérifications faites uniquement à l’écran

Un bouton masqué n’est pas un bouton interdit. Si seule l’interface empêche un commercial de valider une remise ou d’accéder à l’administration, il suffit de contourner l’interface pour le faire. Toutes les règles importantes doivent être vérifiées côté serveur ou dans la base de données, là où l’utilisateur n’a pas la main. Nous expliquons cette différence dans notre article sur ce que l’IA a construit.

3. Des clés secrètes visibles

Pour envoyer des e-mails, encaisser des paiements ou utiliser une IA, votre application utilise des clés d’accès. Les clés secrètes doivent rester sur le serveur. Quand elles se retrouvent dans le code de l’interface, n’importe qui peut les lire dans son navigateur et les utiliser à vos frais. C’est une faille si courante que nous lui consacrons un article entier.

4. Une connexion trop permissive

La gestion des comptes est souvent générée en quelques secondes, avec des réglages par défaut. Vérifiez notamment :

• que l’adresse e-mail est confirmée avant d’accéder à l’application ;
• que les mots de passe trop simples sont refusés ;
• que la réinitialisation du mot de passe ne peut pas être détournée ;
• que les tentatives de connexion répétées sont limitées ;
• que n’importe qui ne peut pas s’inscrire, si votre application est réservée à vos équipes ou à vos clients.

5. Des fichiers accessibles à tous

Les documents envoyés par vos utilisateurs, comme des pièces d’identité, des factures ou des photos, sont rangés dans un espace de stockage. S’il est configuré en accès public, chaque fichier devient consultable par toute personne qui connaît ou devine son adresse. Pour des documents personnels, le stockage doit être privé, et l’accès vérifié à chaque téléchargement.

6. Des réponses trop bavardes

Pour afficher le nom d’un client, l’application va parfois chercher toute sa fiche, y compris des informations que l’écran n’affiche pas : téléphone, adresse, notes internes. Ces données invisibles circulent pourtant jusqu’au navigateur, où elles peuvent être lues. La règle : ne transmettre que ce qui est nécessaire.

7. Pas de sauvegardes, pas d’historique

Ce n’est pas une faille au sens strict, mais c’est ce qui transforme un incident en catastrophe. Sans sauvegarde, une suppression malheureuse ou une erreur de l’IA peut effacer des mois de données. Sans journaux, il est impossible de savoir ce qui s’est passé. Vérifiez que des sauvegardes automatiques existent, et que vous savez les restaurer.

Comment vérifier votre application vous-même

Vous pouvez déjà repérer une bonne partie de ces problèmes sans compétence technique :

1. créez deux comptes de test et vérifiez que chacun ne voit que ses propres données ;

2. avec un compte simple, essayez d’accéder aux pages d’administration en tapant directement leur adresse ;

3. ouvrez un document envoyé par un utilisateur, copiez son adresse et ouvrez-la dans une fenêtre de navigation privée ;

4. consultez les avertissements de sécurité de votre base de données et de votre outil ;

5. demandez à l’IA de votre outil la liste des clés utilisées par l’application et l’endroit où elles sont rangées, en précisant de ne rien modifier.

Si l’un de ces tests révèle un problème, pas de panique : notez-le et corrigez-le avant d’ouvrir l’application à de nouveaux utilisateurs. Et si vous traitez des données sensibles, pensez aussi à vos obligations RGPD.

En résumé

Les failles les plus fréquentes des applications créées avec l’IA sont simples : droits d’accès mal configurés, règles vérifiées seulement à l’écran, clés secrètes visibles, connexion trop permissive, fichiers publics, réponses trop bavardes et absence de sauvegardes. Quelques tests réguliers permettent d’en repérer une bonne partie, et une relecture par un développeur complète le reste avant d’accueillir de vrais utilisateurs. Dans le prochain article, nous nous arrêtons sur la plus coûteuse d’entre elles : les clés API exposées.