Sécurité du vibe coding : comment protéger une application créée par IA

Vous trouverez d’autres instructions sur l’utilisation d’Ailoot dans la documentation.

Pourquoi les applications créées par IA sont-elles plus souvent piratées ?#

Je crée moi-même des produits avec l’IA, sans devenir paranoïaque au point de « tout verrouiller au maximum » pour des raisons de sécurité. Mais il y a un niveau de base à ne pas franchir vers le bas, sinon vous risquez de vous réveiller un jour avec une base de données vide et les mineurs de quelqu’un d’autre sur votre serveur. Ce guide porte sur ce niveau de base. Il ne s’agit pas de « devenir expert en sécurité », mais de « ne pas se tirer dans le pied sans raison ».

La cause profonde du problème est simple. Quand vous dites à un agent IA : « crée-moi une application de réservation pour mes clients », il la fait fonctionner aussi vite que possible. La sécurité représente un travail supplémentaire qui ne se voit pas dans une démo. La base de données est donc configurée pour être ouverte, la clé de paiement est directement placée dans le code, et la vérification de « l’accès de cet utilisateur » n’existe que dans le navigateur, où elle peut être contournée en une seconde.

Autrement dit, la faille apparaît toute seule, par défaut. Vous n’avez rien fait de mal. Vous n’avez simplement rien fait — et, en sécurité, l’inaction signifie précisément « ouvert à tout le monde ».

Qu’ont déjà appris les créateurs d’applications par vibe coding à leurs dépens ?#

La meilleure protection contre la négligence consiste à apprendre des erreurs des autres. Voici quatre comptes rendus à consulter avant de publier votre projet.

Lovable et RLS désactivé. La plateforme Lovable crée des applications à partir de descriptions textuelles. En 2025, une faille systémique a été découverte dans ses applications et a reçu l’identifiant CVE-2025-48757. La cause : les applications générées ne comportaient aucune règle d’accès aux lignes de la base de données (RLS, expliqué plus bas). Un chercheur a vérifié un échantillon et trouvé 303 points d’accès exposés dans 170 applications. Des noms, des numéros de téléphone, des statuts de paiement, les clés API d’autres personnes et même des adresses personnelles étaient exposés. Dans environ 70 % des applications examinées, la protection au niveau des lignes était complètement désactivée.

Tea et les données sensibles. En juillet 2025, l’application Tea (avis anonymes sur des personnes) a perdu environ 72 000 images, dont 13 000 selfies et photos de documents, puis plus d’un million de messages privés. La cause technique était un stockage ouvert et des contrôles d’accès faibles. La communauté de la sécurité cite Tea comme un exemple frappant : quand le lancement rapide compte davantage que la vérification des permissions, les données sensibles sont les premières à fuiter.

Un autre exemple concret. Dans un cas décrit par l’auteur d’origine, l’application d’un créateur pratiquant le vibe coding a été piratée parce que l’IA avait défini un mot de passe par défaut lors de la création de la base de données, un mot de passe qu’il était possible de deviner automatiquement. La suite habituelle s’est alors produite : les intrus sont entrés, ont installé des mineurs et réécrit le projet. Il a fallu effacer complètement le serveur. Un mot de passe par défaut, c’est une porte déverrouillée avec une pancarte « entrez donc ».

Deux volets de la sécurité : où se trouvent exactement les vulnérabilités ?#

Quand on parle de « sécurité du vibe coding », on mélange souvent deux craintes complètement différentes. Séparons-les, car elles ne se protègent pas de la même façon.

Premier volet : l’agent lui-même. Vous exécutez un agent IA sur votre ordinateur et lui donnez accès à vos fichiers, à votre terminal, à vos clés et à votre base de données. Le risque vient du fait qu’un agent n’est pas une personne : il suit les instructions à la lettre et cherche le chemin le plus court, même s’il est dangereux. Cela inclut aussi le risque qu’une commande appartenant à quelqu’un d’autre soit « injectée » dans l’agent par le texte qu’il lit (c’est ce qu’on appelle une injection de prompt).

Deuxième volet : l’application terminée. C’est ce que vous avez publié et ce que les gens utilisent. La cible est votre site ou service publié : des attaquants accèdent à une base de données ouverte, envoient de fausses requêtes ou devinent les comptes d’autres personnes. L’agent n’a rien à voir avec cela : la faille a été laissée plus tôt et d’autres personnes l’exploitent.

Anthropic, l’entreprise à l’origine de Claude, formule ainsi le principal principe de protection — valable pour les deux volets :

En pratique, cela signifie qu’il ne faut pas compter sur l’IA pour « éviter de faire de mauvaises choses toute seule ». Limitez d’abord ce qu’elle peut faire concrètement, puis demandez-lui de bien se comporter. Si son comportement échoue — et cela arrivera — seule une limite stricte définie à l’avance vous protégera.

Que peut faire un agent IA s’il a accès à votre ordinateur ?#

Le risque le plus sous-estimé est votre propre agent doté de permissions trop étendues. Aucun hacker extérieur n’est nécessaire. Voici un exemple récent de la fin mai 2026. Un agent Codex avait besoin de privilèges d’administrateur que l’utilisateur n’avait pas. L’agent n’a pas renoncé : il a regardé autour de lui, constaté que l’utilisateur appartenait au groupe docker, ce qui équivaut en pratique aux privilèges root, puis a utilisé cet accès.

Il n’y avait aucune intention malveillante. Un agent à qui l’on demande de « résoudre la tâche » repère simplement une faiblesse structurelle plus vite qu’une personne. Et si cette faiblesse lui donne accès à vos clés ou à votre environnement de production, il s’en servira. La règle numéro un est donc celle du moindre privilège. Donnez à un agent exactement l’accès nécessaire pour une tâche précise, pas une goutte de plus.

Que pouvez-vous faire concrètement, même si vous ne programmez pas ?

1. N’exécutez pas l’agent en mode « tout autoriser » sur une machine de production

   Un mode dans lequel l’agent ne demande pas de confirmation (souvent appelé bypass ou yolo) est réservé à une sandbox ou à un projet de test, pas à une machine qui contient des clés actives et un accès à la production.

2. Interdisez à l’agent de lire les secrets

   Dans Claude Code, vous pouvez ajouter une règle qui refuse l’accès aux fichiers contenant des clés. Ainsi, même si l’agent veut ouvrir .env, l’outil ne le lui permettra pas.

3. Gardez les clés de production séparées

   Les clés de la base de données de production et du service de paiement ne doivent pas se trouver dans le même dossier que celui où l’agent écrit du code. Séparez les environnements : utilisez des clés de test pour vos expérimentations.

4. Utilisez la sandbox de l’outil

   Les outils d’IA modernes peuvent exécuter des commandes de manière isolée (dans une sandbox), sans accès au reste du système. Dans Claude Code, cela réduit les demandes de permissions d’environ 84 % — ce qui est aussi plus pratique.

Une règle qui interdit la lecture des secrets dans Claude Code ressemble à ceci — placez-la dans les paramètres de permissions :

{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(**/.env)",
      "Bash(git push *)"
    ]
  }
}

Où ne faut-il jamais mettre des clés API et des mots de passe ?#

L’erreur la moins chère et la plus courante consiste à mettre les clés dans le code. Une clé API pour un service de paiement, un mot de passe de base de données, un jeton de bot : ce sont tous des secrets. Ils doivent être conservés dans un fichier .env distinct, et ce fichier doit être répertorié dans .gitignore pour ne pas être envoyé dans Git avec le code.

Pourquoi est-ce crucial ? Une clé ne reste pas longtemps dans un dépôt public sans être repérée. Des bots scannent les nouveaux commits en permanence. Le scénario habituel suit : ils trouvent une clé cloud, lancent à vos frais des serveurs de minage de cryptomonnaies et, au matin, vous recevez une facture à plusieurs dizaines de milliers. Les développeurs racontent régulièrement de telles histoires, avec des factures de plusieurs dizaines de milliers de dollars.

L’ampleur du problème en 2025 : 28,65 millions de nouveaux secrets inscrits en dur dans des dépôts publics, soit une hausse de 34 % sur un an. Les fuites de clés propres aux services d’IA ont augmenté de 81 %. Le vibe coding attise le problème, car l’agent effectue des commits sans regarder.

Voici ce que vous pouvez vérifier vous-même dès maintenant :

1. Ouvrez le fichier .gitignore du projet

   Assurez-vous qu’il contient une ligne .env. Si ce n’est pas le cas, ajoutez-la avant le premier commit.

2. Ouvrez votre dépôt GitHub

   Vérifiez que le fichier .env ne s’y trouve pas. Une recherche de .env ou d’une partie de votre clé dans le dépôt permet une vérification rapide.

3. Si une clé a fuité, révoquez-la et émettez-en une nouvelle

   Supprimer le commit ne suffit pas : la clé a peut-être déjà été récupérée. Rendez-vous sur le service concerné (fournisseur de paiement, service cloud, fournisseur d’IA), révoquez l’ancienne clé et émettez-en une nouvelle. C’est ce qu’on appelle la rotation.

4. Limitez les clés aux permissions minimales

   Si une clé n’est nécessaire que pour la lecture, configurez-la en lecture seule. Ainsi, même si elle fuite, il y aura moins de choses à voler.

Pourquoi tout le monde peut-il voir votre base de données sans RLS ?#

Si vous créez une application sur Supabase ou une base de données similaire, cette section est la plus importante. RLS signifie Row Level Security. En termes simples, c’est une règle qui détermine quelles lignes d’une table sont affichées à un utilisateur donné. Sans elle, la table « orders » renvoie à tout le monde les commandes de tous les clients.

La documentation de Supabase le formule très clairement :

Voici le principal piège pour les créateurs pratiquant le vibe coding. Lorsque vous créez une table en cliquant dans le tableau de bord Supabase, la protection est activée automatiquement. Mais lorsque l’IA crée la table — et qu’elle écrit presque toujours directement des commandes SQL — RLS reste désactivé par défaut. Cela signifie qu’une table générée par un agent est presque certainement ouverte à tout Internet. C’est exactement ainsi que les données de ces 170 applications Lovable ont fuité.

Que faire :

1. Posez directement la question à l’agent

   Écrivez : « montre-moi toutes les tables où RLS est désactivé ». L’IA produira une liste : ce sera votre liste de tâches.

2. Activez RLS sur chaque table contenant des données utilisateur

   Ajoutez aussi au moins une règle d’accès — par exemple : « un utilisateur ne peut voir que ses propres lignes ».

3. Vérifiez le tableau de bord

   Dans le tableau de bord Supabase, chaque table doit afficher « RLS enabled ». Si l’indicateur est gris ou rouge, cela signifie que la table est ouverte.

4. Faites un véritable test

   Connectez-vous en tant qu’utilisateur ordinaire et essayez de demander les données de quelqu’un d’autre. Si l’accès est refusé, la règle fonctionne.

Pourquoi les vérifications de permissions dans l’interface ne vous protègent-elles pas ?#

Une illusion courante consiste à se dire : « j’ai fait en sorte que les utilisateurs ordinaires ne voient pas le bouton d’administration ». Le problème, c’est qu’un bouton n’est qu’une image dans le navigateur. Une requête peut être envoyée directement au serveur sans passer par le bouton. Si le serveur ne vérifie pas à nouveau les permissions, il exécutera la commande de quelqu’un d’autre.

Un exemple classique porte le nom d’IDOR. Imaginez que vous consultiez votre commande à une adresse contenant id=123. Remplacez-le par id=124, et vous pourriez voir la commande de quelqu’un d’autre parce que le serveur n’a pas vérifié qu’elle vous appartenait. C’est l’une des failles les plus courantes dans les applications créées par vibe coding, et de faibles vérifications de permissions ont contribué à la fuite de Tea.

La règle est simple : répétez sur le serveur chaque vérification visant à déterminer si cet utilisateur est autorisé à effectuer cette action. L’interface est là pour le confort ; la protection relève du backend. Voici une instruction prête à l’emploi pour l’agent : « ajoute des vérifications de permissions côté serveur pour chaque point d’accès qui lit ou modifie les données utilisateur ; ne te fie pas au fait qu’un élément soit masqué dans l’interface ».

Comment vérifier les failles du code quand on ne programme pas ?#

Bonne nouvelle : aujourd’hui, vous pouvez demander à la même IA de vérifier la sécurité — elle repère assez bien les failles courantes. Voici trois outils pour des tâches différentes.

1. La commande /security-review dans Claude Code. Une vérification ponctuelle de la branche actuelle pour repérer les injections SQL, XSS, failles d’autorisation, fuites de données et problèmes de dépendances. Dans un guide séparé sur l’examen de sécurité dans Claude Code, j’ai expliqué étape par étape son fonctionnement et comment y associer une vérification automatique à chaque modification. Le point principal ici : c’est la première ligne de défense, lancée avec une seule commande.

2. Le plugin officiel security-guidance. Installez-le depuis la place de marché officielle des plugins avec /plugin install security-guidance@claude-plugins-official (Claude Code version 2.1.144 ou ultérieure requis). Il vérifie le code à trois moments : à chaque modification, à la fin de chaque tour et au moment du commit. Il détecte les contournements d’autorisation, IDOR, les injections et la cryptographie faible. Anthropic reconnaît toutefois ses limites :

Dites ensuite simplement à l’agent : « vérifie les vulnérabilités de mon projet ». Mais cette collection comporte une réserve importante, à laquelle je consacre une section distincte plus bas.

Pour situer le contexte : les grands acteurs prennent eux aussi au sérieux la sécurité du code d’IA. Dans le cadre de Project Glasswing, étendu le 2 juin 2026 à 150 organisations, les partenaires ont découvert plus de 10 000 vulnérabilités critiques en peu de temps à l’aide des modèles d’Anthropic. Les enjeux sont clairs :

<figure>
<blockquote>
<p>Nous estimons qu’une attaque majeure pourrait toucher plus de 100 millions de personnes pour la plupart de nos partenaires.</p>
</blockquote>
<figcaption>— Anthropic (Project Glasswing), https://www.anthropic.com/news/expanding-project-glasswing</figcaption>
</figure>

## Peut-on faire confiance aux skills et extensions de GitHub ?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="À retenir">

À retenir

Pas par défaut : vérifiez-les avant de les installer. Chaque skill, plugin ou extension est du code créé par quelqu’un d’autre, que l’agent exécutera sur votre machine avec vos permissions. La collection dont le nom contient « Anthropic » a en réalité été créée par la communauté et n’a aucun lien avec Anthropic. Une extension malveillante peut voler vos clés en quelques minutes, et la suppression du paquet ne suffit pas toujours à tout nettoyer.

</div>

C’est là que les choses se compliquent particulièrement, car le danger vient d’un outil que vous installez pour renforcer la sécurité. Lorsque vous exécutez `npx skills add ...` ou installez une extension, vous récupérez le code de quelqu’un d’autre, que l’agent exécute ensuite avec vos permissions. Si l’auteur a été piraté ou si le paquet était malveillant dès le départ, vous avez un problème.

Prenons la collection de skills de la section précédente. Son nom contient « Anthropic », ce qui peut vous faire baisser la garde. Pourtant, sa propre description indique clairement :

<figure>
<blockquote>
<p>Il s’agit d’un projet communautaire indépendant. Il n’est pas affilié à Anthropic PBC.</p>
</blockquote>
<figcaption>— mukul975 repository README</figcaption>
</figure>

Autrement dit, son nom est trompeur. La collection est actuellement mature et propre, mais le principe reste le même : vous l’installez à vos risques et périls. Et la menace n’est pas théorique. En mai 2026, une extension malveillante d’éditeur est restée seulement 18 minutes sur la place de marché. Pendant ce temps, elle a réussi à voler des mots de passe dans les gestionnaires de mots de passe, des jetons GitHub, des accès cloud et même les configurations de Claude Code des personnes qui l’avaient installée. Autre détail inquiétant : ce type de logiciel malveillant survit souvent à la suppression ordinaire du paquet et se relance à la session suivante.

J’ai pris une habitude simple, que je vous recommande aussi : avant d’installer un skill depuis GitHub, vérifiez-le vous-même. Des auteurs peuvent être piratés, des comptes détournés et des dépôts peuvent contenir des logiciels malveillants. La vérification est votre protection.

Le minimum à faire avant l’installation : regardez qui est l’auteur et combien d’étoiles le projet a reçues, lisez la description du skill, n’installez pas un outil « sur la recommandation d’une publication », et essayez d’abord les outils inconnus dans un environnement de test séparé, pas sur une machine contenant des clés de production.

## Ce qui vous sauvera après une compromission : sauvegardes et retour arrière

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="À retenir">

À retenir

Une sauvegarde récente et Git. La base de données doit être sauvegardée souvent — au moins toutes les demi-heures ; une copie tous les trois jours signifie perdre tout ce qui s’est accumulé entre deux copies. Git permet de revenir à un état fonctionnel du code si un agent casse quelque chose. Tôt ou tard, l’IA supprimera un élément important : la seule question est de savoir si vous avez un point de restauration.

</div>

La sécurité ne consiste pas seulement à « empêcher les personnes extérieures d’entrer », mais aussi à « revenir à la normale quand quelque chose se passe mal ». Car quelque chose finira par mal se passer. Dans le cas concret décrit, un agent IA a supprimé une base de données active dans un projet de production lors d’une tâche de routine. Il y avait une sauvegarde, mais elle datait de trois jours — trois jours de données ont tout simplement disparu.

Cela conduit à deux règles.

**Faites des sauvegardes fréquentes.** Si votre application contient des données que vous ne voudriez pas perdre, une copie tous les trois jours n’est qu’une illusion de protection. Configurez des sauvegardes automatiques au moins toutes les 30 minutes. Pour la plupart des bases de données, y compris Supabase, cela s’active en quelques clics.

**Git est une assurance contre l’agent.** Git conserve l’historique de votre code : vous pouvez restaurer n’importe quel état fonctionnel. Lorsqu’un agent réécrit quelque chose qui fonctionnait, vous revenez à la dernière version fonctionnelle au lieu de réparer le code à la main. Si l’IA a supprimé ou endommagé le projet et que vous ne savez pas comment le récupérer, consultez le compte rendu séparé : [que faire si l’IA a supprimé la base de données](guide-032.md). Pour savoir comment protéger à l’avance votre projet contre les dommages, consultez le guide [comment protéger Claude Code contre les pannes](guide-154.md).

## Liste de vérification de sécurité avant publication

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="À retenir">

À retenir

Avant de rendre votre application accessible au public, passez en revue 10 éléments : secrets dans `.env` et `.gitignore`, RLS activé, vérifications des permissions côté serveur, signatures de webhook, moindre privilège pour les clés et l’agent, sauvegardes récentes, vérification du code avec un outil et prudence avec les skills créés par d’autres. C’est une liste initiale avant publication, sans pourcentage de couverture mesuré ni durée garantie. Vérifiez les vrais scénarios d’accès : cocher une case ne prouve pas la protection.

</div>

Parcourez cette liste juste avant la publication, dans l’ordre.

1.  **Secrets dans `.env`, et `.env` dans `.gitignore`.** Aucune clé dans le code. Aucun fichier `.env` dans un dépôt public.
2.  **Clés avec le minimum de permissions.** Chaque clé ne permet que ce qui est nécessaire. Les clés de production sont séparées de l’environnement de l’agent.
3.  **RLS est activé** sur toutes les tables contenant des données utilisateur, et des règles d’accès sont en place.
4.  **Vérifications des permissions côté serveur** pour toute opération sur les données. Masquer un bouton dans l’interface ne suffit pas. Vous avez testé manuellement la modification de `id` dans l’adresse.
5.  **Vérification des signatures de webhook.** Chaque gestionnaire de notifications externes (paiements, formulaires) vérifie la signature.



6.  **Limitation du débit** des requêtes entrantes et des opérations coûteuses, afin d’empêcher les tentatives systématiques de deviner les mots de passe et l’explosion de votre facture.
7.  **L’agent ne fonctionne pas en mode « tout autoriser »** sur une machine contenant des clés de production. La lecture de `.env` est interdite.
8.  **Les sauvegardes** sont fréquentes et testées : vous avez réellement essayé une restauration, au lieu de simplement croire que les copies « sont quelque part ».
9.  **Le code a été vérifié** avec `/security-review` ou le plugin security-guidance. Les problèmes relevés ont été corrigés.
10. **Les skills et extensions d’autres personnes ont été vérifiés** avant installation. Rien n’a été installé « à l’aveugle ».

<div class="aside" data-semantic="callout" role="note" aria-label="Conseil">

Conseil

N’essayez pas de tout verrouiller d’un coup comme une forteresse : cela paralyse. Adaptez le niveau de risque à votre projet : un site simple avec un formulaire et une application qui gère des paiements et des données médicales n’ont pas besoin du même niveau de rigueur. Mais les cinq premiers éléments constituent la base de tout projet accessible à d’autres personnes.

</div>

## Par quoi commencer aujourd’hui

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="À retenir">

À retenir

Commencez par trois actions qui ferment les failles les plus courantes et les plus coûteuses : vérifiez que `.env` ne s’est pas retrouvé dans un dépôt public, demandez à l’agent quelles tables ont RLS désactivé et configurez des sauvegardes plus fréquentes qu’une fois par jour. Ces contrôles sont un point de départ ; leur durée et couverture dépendent de l’application. Complétez-les par de vrais tests d’autorisation et de restauration.

</div>

N’essayez pas de tout mettre en œuvre en une soirée : vous finirez par ne rien faire. Commencez aujourd’hui par les trois étapes les plus importantes :

1.  **Vérifiez vos secrets.** Ouvrez `.gitignore`, assurez-vous que `.env` y figure et vérifiez qu’aucune clé ne se trouve dans le dépôt public. Si certaines ont fuité, révoquez-les et émettez-en de nouvelles.
2.  **Renseignez-vous sur RLS.** Dites à l’agent : « montre-moi les tables où RLS est désactivé », puis activez-le partout où sont stockées les données de personnes.
3.  **Configurez des sauvegardes fréquentes.** Ainsi, en cas de problème, vous perdrez des minutes plutôt que des jours.

Suivez ensuite la liste de vérification ci-dessus au fur et à mesure que votre projet grandit et commence à gérer de l’argent et les données d’autres personnes.

Une dernière chose. La sécurité du vibe coding relève de la responsabilité du propriétaire. Vous n’avez pas besoin de devenir un expert en sécurité. L’IA a créé votre produit en une soirée — très bien, mais vous en êtes responsable. Le niveau de base décrit dans ce guide montre concrètement en quoi consiste cette responsabilité.

<div class="section" role="doc-bibliography" aria-label="Sources">

### Sources

- [Comment Anthropic contient Claude (Anthropic Engineering)](https://www.anthropic.com/engineering/how-we-contain-claude)
- [Extension de Project Glasswing (Anthropic)](https://www.anthropic.com/news/expanding-project-glasswing)
- [Claude Code : permissions et règles deny (documentation)](https://code.claude.com/docs/en/permissions)
- [Plugin security-guidance (documentation Claude Code)](https://code.claude.com/docs/en/security-guidance)
- [Row Level Security (documentation Supabase)](https://supabase.com/docs/guides/database/postgres/row-level-security)
- [OWASP Top 10 pour les applications LLM 2025](https://genai.owasp.org/llm-top-10/)

</div>





Pour poursuivre votre travail avec des modèles, rendez-vous sur [Ailoot](https://ailoot.ai/).