Aller au contenu
Chapitre 01 · 9 min

Pourquoi les apps construites par IA sortent non sécurisées

Les outils de codage IA sont extraordinaires pour produire des logiciels qui fonctionnent. Ils restent silencieux sur la partie du logiciel qui continue de fonctionner en sécurité quand des inconnus se présentent. Cet écart est prévisible, il a une forme, et ce cours explique comment le combler avant votre lancement. Ce chapitre explique pourquoi l'écart existe.

Un entrepreneur qui construit exactement ce que vous décrivez, vite, et ne mentionne jamais les normes du bâtiment, parce que vous n'avez pas demandé.

lock downprotectlaunchInsecure defaultRLS + secretsAuth + endpointsHardened

L'écart entre « ça marche » et « c'est sûr »

Demandez à un outil IA de construire une fonctionnalité et il optimise pour ce que vous pouvez voir : l'écran s'affiche, le bouton soumet, les données apparaissent. C'est la démo, et la démo passe. La sécurité est la partie que vous ne pouvez pas voir dans la démo : la vérification qu'un utilisateur ne peut pas lire les données d'un autre, la clé qui ne devrait pas être dans le navigateur, l'endpoint qui devrait refuser une requête non authentifiée. Rien de tout cela ne change l'apparence du chemin heureux, donc rien n'est construit à moins que quelqu'un ne le demande.

Ce n'est pas une critique des outils. C'est une description de ce pour quoi ils ont été entraînés : produire du code qui satisfait la demande. « Construis-moi un tableau de bord où les utilisateurs voient leurs commandes » produit un tableau de bord où les utilisateurs voient leurs commandes. Cela ne produit pas « ... et où l'utilisateur A ne peut prouvablement pas atteindre les commandes de l'utilisateur B », parce que vous ne l'avez pas dit, et dans la démo, avec un seul utilisateur connecté, la différence est invisible.

Pourquoi le modèle laisse les trous

Trois forces se cumulent. Le modèle remplit avec le schéma le plus courant de ses données d'entraînement, et une grande partie de ces données sont des tutoriels et du code de démarrage rapide qui n'ont jamais été conçus pour la production. Il n'a aucune vue sur votre modèle de menace : il ne sait pas s'il s'agit d'un projet de loisir ou d'un traitement de données de paiement. Et chaque cycle de prompting peut discrètement défaire une protection d'un cycle précédent, parce que le modèle optimise la demande courante, pas la préservation de la précédente.

Une vraie faille, en détail

En 2025, un chercheur en sécurité, Matt Palmer, a parcouru 1 645 applications construites sur la plateforme IA Lovable et a trouvé 303 endpoints non sécurisés répartis sur 170 d'entre elles (environ une sur dix) où n'importe qui pouvait lire, modifier ou supprimer n'importe quelle ligne de la base de données. Les données exposées incluaient des noms, des numéros de téléphone, des informations de paiement et des clés API. La cause racine n'avait rien d'exotique : les apps générées parlaient directement à leur base de données depuis le navigateur, sans aucune règle d'accès au niveau des lignes. C'est devenu la CVE-2025-48757, classée critique (CVSS 9,3).

Rien dans ces 170 apps ne semblait cassé. Elles ont été livrées, elles fonctionnaient, de vrais utilisateurs se sont inscrits. Le trou était structurel et invisible depuis le front-end, exactement le genre d'écart dont parle ce cours. Les chiffres qui circulent avec ce type d'histoires (« X millions de clés fuitées ») sont souvent non vérifiés ; la CVE documentée suffit à elle seule à faire la démonstration.

Les cinq trous, et la suite de ce cours

La bonne nouvelle : les trous ne sont ni infinis ni mystérieux. Les apps construites par IA fuient dans un petit nombre d'endroits prévisibles, et chacun correspond à un chapitre :

  • Accès aux données : la base de données fait confiance au navigateur, donc n'importe quel utilisateur peut atteindre n'importe quelle ligne (chapitre 2).
  • Secrets : les clés API et les identifiants finissent dans le code client ou dans git (chapitre 3).
  • Autorisation : la connexion existe, mais les vérifications de propriété par ressource n'existent pas (chapitre 4).
  • Surface exposée : endpoints oubliés, API ouvertes et webhooks non vérifiés (chapitre 5).
  • Tout le reste avant le lancement : en-têtes, dépendances, erreurs, et la checklist qui attrape le reste (chapitre 6).

Parcourez-les dans l'ordre et vous fermerez les écarts qui ont produit des incidents comme la CVE de Lovable. Rien de tout cela n'exige d'être spécialiste en sécurité. Cela exige de connaître les cinq endroits où regarder et ce que « terminé » veut dire pour chacun.

En une ligne chacun

  • Les outils IA optimisent pour la démo visible, pas pour les protections invisibles : la sécurité est la partie que personne ne prompte.
  • Les trous générés ont l'air finis : l'app fonctionne parfaitement pour le seul testeur qui a la permission de tout voir.
  • La CVE-2025-48757 a exposé ~170 apps Lovable via l'absence de règles d'accès à la base : structurel et invisible depuis le front-end.
  • Les trous sont prévisibles et peu nombreux : accès aux données, secrets, autorisation, surface exposée, et durcissement pré-lancement.
Pourquoi les apps construites par IA sortent non sécurisées · Cours d'IA · SDEN