La sécurité quand on vibecode : ce que l'IA ne vérifie pas pour toi

Table des matières

L'IA code vite. Elle génère des features en quelques minutes. Elle gère les edge cases (ces cas particuliers auxquels tu n'aurais pas pensé, du genre "et si l'utilisateur entre une date dans le futur ?"). Elle gère les validations si tu lui expliques comment faire (si tu lui expliques comment faire).

Les failles citées ici sont datées : CVE-2025-48757 sur Lovable remonte à mai 2025, et le chiffre des secrets exposés sur GitHub à l'année 2024. Elles servent d'exemples, pas d'état de la menace. Les principes, eux, ne bougent pas.

Mais elle ne pense pas sécurité.

Et toi non plus au début. C'est normal.

Quand ton app marche enfin, t'as pas envie de chercher des failles. Tu veux déployer. Et puis tu as encore tellement de features à développer, l'UX à améliorer, des bugs qui apparaissent sans cesse... Pas le temps pour la sécurité. Et puis c'est bon, t'as un mot de passe pour l'admin, ça suffit non ?

Non.

Voici les 4 catégories de risques à connaître quand on vibecode.

1. Les secrets dans le code

C'est le piège le plus bête. Et le plus fréquent.

L'IA met parfois des clés API directement dans le code. Ou elle crée un fichier .env mais oublie de l'ajouter au .gitignore. Tu commit, tu push, et ta clé Stripe est sur GitHub.

Stat choc : 39 millions de secrets ont été exposés sur GitHub en 2024.

Des bots scannent GitHub en temps réel. Ta clé peut être exploitée en quelques minutes.

La solution :

Crée ton .gitignore AVANT le premier commit
Mets .env et tous les fichiers secrets dedans
Installe Gitleaks pour bloquer les commits dangereux

brew install gitleaks

Gitleaks scanne ton code et refuse le commit si un secret est détecté.

C'est le minimum, et il suffit largement pour démarrer. Sache juste qu'il existe une marche au-dessus : sortir complètement les secrets du projet, pour qu'ils vivent dans un gestionnaire dédié et soient injectés au moment de lancer la commande. Il n'y a alors plus de fichier à oublier dans un commit, parce qu'il n'y a plus de fichier. C'est ce que j'utilise aujourd'hui, mais ne commence pas par là : un .gitignore écrit avant le premier commit règle déjà la grande majorité des accidents.

Si tu commites un secret par erreur :

Révoque-le immédiatement (dashboard Stripe, Supabase, etc.)
Génère un nouveau secret
Supprimer le fichier ne suffit pas, il reste dans l'historique Git

→ J'en parle plus en détail dans Git pour vibecoder

2. Supabase : le piège de la service_role key

Si tu utilises Supabase, tu as deux clés :

Clé	Permissions	Où l'utiliser
`anon`	RLS appliqué	Frontend (client)
`service_role`	Bypass RLS total	Backend uniquement

La service_role key, c'est le mode God. Elle contourne toutes les règles de sécurité Row Level Security. Avec elle, tu peux lire, modifier, supprimer n'importe quelle donnée de n'importe quel utilisateur.

Le problème : c'est tentant de l'utiliser partout parce que "ça marche". Plus besoin de configurer les RLS, plus d'erreurs de permissions...

Sauf que si quelqu'un récupère cette clé (et côté client, c'est facile), il a accès à toute ta base.

Cas réel : CVE-2025-48757 (Lovable)

170 applications sur les 1 645 scannées, soit une sur dix
Listes d'utilisateurs et coordonnées de paiement accessibles
Jetons de réinitialisation de mot de passe exposés, donc prise de contrôle des comptes

L'attaque était simple : les tables n'avaient pas de RLS, et la clé était exposée côté client.

La règle :

// ❌ JAMAIS côté client
const supabase = createClient(url, process.env.NEXT_PUBLIC_SERVICE_KEY)

// ✅ Frontend
const supabase = createClient(url, process.env.NEXT_PUBLIC_ANON_KEY)

// ✅ Backend (API Route, Server Action)
const supabaseAdmin = createClient(url, process.env.SUPABASE_SERVICE_ROLE_KEY)

Et active les RLS sur toutes tes tables, même celles qui te semblent "pas sensibles".

→ Pour configurer tes RLS correctement, j'ai écrit Supabase RLS : le guide complet

3. Les dépendances vulnérables

L'IA utilise des packages. Beaucoup de packages. Et certains ont des failles de sécurité.

Mon exemple : début décembre 2025, une faille critique est découverte dans React et Next.js, CVE-2025-55182, surnommée "React2Shell".

Score CVSS : 10.0 sur 10. Le maximum.

Exécution de code à distance, sans authentification. Le genre de truc où tu mets à jour avant de finir ton café.

J'ai mis à jour tous mes projets. Et là, mon Mac a freeze. Mais c'est une autre histoire.

Comment faire ta veille :

# Vérifier les vulnérabilités connues
pnpm audit
# ou
npm audit

# Mettre à jour
pnpm update

Outils automatiques :

Dependabot (GitHub) : crée des PRs automatiques quand une dépendance a une faille
Snyk : scan plus approfondi, version gratuite disponible

Où suivre les CVE :

Next.js Blog, section Security
React Blog
NVD, la base de données nationale des vulnérabilités

Un quart d'heure par semaine sur ces trois sources suffit à ne pas découvrir une faille critique six mois trop tard. Je détaille tout mon système de veille ici.

4. Les vulnérabilités classiques (XSS, injection)

L'IA peut introduire des failles classiques sans le savoir. Voici les plus courantes :

XSS (Cross-Site Scripting)

Un attaquant injecte du JavaScript malveillant dans ton site. Quand un autre utilisateur visite la page, le script s'exécute dans son navigateur.

Exemple : un champ commentaire qui n'échappe pas le HTML. Quelqu'un poste <script>volerCookies()</script>.

Injection SQL

L'attaquant envoie du SQL dans un champ de formulaire pour manipuler ta base de données.

Exemple : ' OR 1=1 -- dans un champ login = accès à tout.

IDOR (Insecure Direct Object Reference)

Tu accèdes à /user/123/factures et tu changes en /user/124/factures = tu vois les factures d'un autre.

Comment vérifier

L'IA ne va pas forcément détecter ces failles. Toi non plus si tu ne sais pas quoi chercher.

Règles de base :

Valide tous les inputs côté serveur (pas juste côté client)
Échappe les outputs avant de les afficher
Vérifie les permissions à chaque requête (l'utilisateur a-t-il le droit d'accéder à cette ressource ?)

Si tu utilises Next.js + Supabase avec les RLS bien configurées, tu es déjà protégé contre une bonne partie de ces attaques.

5. Le prompt injection : quand l'IA devient le vecteur

Les quatre premiers points concernent ce que l'IA oublie de vérifier. Celui-ci est différent : c'est elle qu'on attaque.

Ton assistant ne fait pas la différence entre ce qu'il doit lire et ce qu'il doit exécuter. Tout arrive dans le même flux de texte. Une page web, un README, un ticket sur un dépôt public, le nom d'un fichier : si ça contient une phrase bien tournée qui ressemble à une consigne, il peut la suivre.

Le cas qui fait comprendre

En mai 2025, des chercheurs ont montré l'attaque suivante. Un attaquant ouvre un ticket anodin sur un dépôt public. Tu demandes à ton assistant de regarder les tickets ouverts. Il lit le ticket, y trouve des instructions cachées, et va chercher des données dans tes dépôts privés pour les recopier dans une réponse publique.

Personne n'a eu besoin d'un accès à ton code. Il a suffi d'ouvrir un ticket, ce que n'importe quel compte gratuit peut faire.

Variante qui parle encore plus à un vibecodeur : des instructions dissimulées dans un fichier de rules, avec des caractères Unicode invisibles à la relecture. Le fichier a l'air normal à l'écran, et l'IA y lit autre chose que toi.

Ce que tu fais

La règle tient en une phrase : ce que ton IA lit est du contexte, jamais un ordre. Une consigne ne vaut que si elle vient de toi.

Traiter comme non fiable tout ce qui vient de l'extérieur : tickets, README, pages scrapées, dépendances, et même les noms de fichiers
Ne pas donner à ton agent un jeton qui ouvre tous tes dépôts quand il n'en traite qu'un
Relire ce qu'il s'apprête à envoyer dehors, plus encore que ce qu'il écrit dans ton code
Se méfier d'une réponse qui part soudain dans une direction que tu n'as pas demandée : c'est le symptôme le plus visible

Et si ton app envoie elle-même du contenu d'utilisateur à un modèle, tu hérites du même problème, à ta charge cette fois.

Checklist rapide

Avant de déployer, vérifie :

☐ .gitignore avec .env AVANT le premier commit
☐ Gitleaks installé (brew install gitleaks)
☐ service_role key jamais côté client
☐ RLS activé sur toutes les tables Supabase
☐ pnpm audit sans vulnérabilités critiques
☐ Veille CVE sur ta stack (Next.js, React, tes libs principales)
☐ Ton serveur durci : pare-feu, SSH par clé, mises à jour automatiques
☐ Les jetons de ton agent limités au strict nécessaire

Pour aller plus loin

Tout ce qui précède concerne ton application. Le serveur sur lequel elle tourne est l'autre moitié du sujet, et elle se fait attaquer sans que personne vise ton app en particulier : ça m'est arrivé, et des robots scannent les ports en permanence.

Sécuriser son VPS, le guide complet du durcissement, pare-feu, SSH et compagnie
On a hacké mon VPS, ce que ça fait quand ça arrive vraiment
Supabase RLS : le guide complet, pour configurer les Row Level Security
Git pour vibecoder, le filet de sécurité indispensable

Le mot de la fin

L'IA code. Toi, tu sécurises.

C'est pas glamour. C'est pas fun. Mais c'est ce qui fait la différence entre une app qui marche et une app qui se fait pirater.

Dans mon accompagnement, je te montre comment intégrer ces vérifications dans ton workflow sans que ça devienne une corvée. Parce que la sécurité, c'est comme les tests : si c'est chiant, tu le feras pas.