Cursor et l'IA en pair programming : les erreurs de sécu qui reviennent
Cursor n'est pas un générateur d'app comme Bolt, Lovable ou v0 — c'est un éditeur de code avec un agent IA qui lit, modifie et écrit directement dans un projet déjà existant. Le risque qui en découle est différent : ce n'est pas un backend généré d'un coup sans RLS, c'est une série de petites modifications faites en confiance, dont certaines touchent à des secrets sans que personne ne les relise ligne par ligne.
L'agent ne connaît pas tes intentions de sécurité
Quand tu demandes à l'agent Cursor "ajoute l'intégration Stripe" ou "connecte cette route à la base", il produit du code qui fonctionne — c'est son critère de réussite. Rien ne l'empêche de coller une clé trouvée dans ton .env directement dans un composant client parce que c'est le chemin le plus court pour faire marcher la démo, surtout si le prompt ne précise pas explicitement où le code doit s'exécuter :
// suggestion plausible d'un agent qui optimise pour "ça marche"
// components/CheckoutButton.tsx (fichier client)
const stripe = new Stripe("sk_live_..."); // ❌ exécuté dans le navigateurLe code compile, le paiement fonctionne en test, et la clé secrète part dans le bundle JS public sans qu'aucune alerte ne se déclenche — l'agent n'a pas de notion de "cette variable ne doit jamais atteindre le client" à moins qu'on le lui dise.
Le diff est plus facile à accepter qu'à relire
L'agent en mode autonome peut enchaîner plusieurs fichiers modifiés d'un coup, avec un bouton "accepter tout". C'est là que les changements liés aux secrets passent le plus souvent inaperçus : une variable renommée, un exemple de configuration collé depuis la documentation d'un service tiers avec une vraie clé dedans plutôt qu'un placeholder, un fichier .env généré puis committé parce que le .gitignore du projet ne le couvrait pas encore à ce moment-là.
Le correctif
Relis spécifiquement les diffs qui touchent à l'authentification, aux paiements ou à la configuration — pas juste survoler qu'il n'y a pas d'erreur de build. Confirme que .env est bien dans .gitignore avant le tout premier commit, pas après coup :
# .gitignore — à vérifier dès le premier commit du projet
.env
.env.local
.env*.localUn hook pre-commit qui scanne les patterns de clés connus (sk_live_, AKIA...) avant chaque push attrape ce que la relecture manque parfois. Détails et autres patterns fréquents : Clés API et secrets en dur dans le code et .env ou .git exposés publiquement.
Un projet fait évoluer à coups de prompts Cursor et déjà en ligne ? Scanne-le pour vérifier qu'aucun secret ne s'est glissé dans le JavaScript public au fil des itérations.