Sécurité pour le code que tu écris avec Cursor

« Sécurité de Cursor » veut dire deux choses différentes, et il vaut mieux les séparer. La première, c'est protéger ta propre configuration de Cursor : ce qui quitte ta machine, ce que l'agent peut exécuter sans te demander, et à quels serveurs et fichiers de règles tu fais confiance. La seconde, c'est protéger le code que Cursor écrit pour toi, celui qui finit déployé et exposé à internet. Ce guide couvre les deux, avec un bloc de règles prêt à coller dans ton projet et un prompt de revue à lancer avant chaque déploiement.

Partie 1 : protéger ta configuration de Cursor

Ce qui quitte ta machine

Cursor envoie à ses serveurs, et à ceux du fournisseur du modèle, le contexte dont il a besoin pour répondre : le fichier ouvert, ce qu'il indexe du projet et ce que tu colles dans le chat. Active le mode privé dans les réglages si tu ne veux pas que ce code soit stocké ni utilisé pour l'entraînement ; en équipe, impose-le depuis le plan. Et souviens-toi que tout ce que tu colles dans le chat voyage : ne colle pas de dumps de base de données ni de fichiers d'identifiants « pour qu'il comprenne ».

Exclure les secrets de l'indexation

Cursor indexe le projet pour donner du contexte au modèle. Un .env, un service-account.json ou un dossier de certificats ne devraient pas faire partie de cet index. Crée un fichier .cursorignore à la racine avec les motifs à exclure ; il suit la syntaxe de .gitignore :

.env
.env.*
*.pem
*.key
**/service-account*.json
secrets/

Si quelque chose de sensible était déjà indexé, retire-le de l'index dans les réglages et, si c'était une vraie clé, fais-la tourner.

Exécution automatique des commandes

L'agent de Cursor peut exécuter des commandes de terminal tout seul si tu le lui permets. C'est pratique et c'est dangereux : un prompt mal compris, ou un texte malveillant que l'agent lit dans un fichier ou sur une page web, peut finir en rm -rf, en git push --force ou en curl | sh. Garde la confirmation manuelle pour les commandes qui suppriment, publient ou installent, n'utilise la liste d'autorisation que pour des choses inoffensives (tests, lint, build) et ne donne jamais à l'agent des identifiants de production dans son environnement.

Serveurs MCP tiers

Les serveurs MCP étendent ce que l'agent peut faire : lire ta base de données, appeler des API, piloter le navigateur. Chacun est du code qui tourne avec tes permissions et dont le modèle lit les descriptions d'outils comme des instructions. N'installe que des serveurs de sources que tu connais, vérifie ce qu'ils demandent, préfère ceux qui fonctionnent avec des identifiants en lecture seule et surveille les changements de configuration : un serveur qui change sa définition après que tu l'as approuvé est un signal d'alarme.

Fichiers de règles venus d'autres dépôts

Les fichiers de règles (.cursor/rules, .cursorrules) sont des instructions que le modèle suit à chaque requête. Si tu clones un dépôt, un template ou un exemple trouvé sur internet, il peut contenir des règles que tu ne vois pas au premier coup d'œil, voire des caractères invisibles qui cachent des instructions pour glisser du code malveillant. Ouvre et lis les fichiers de règles de tout projet que tu n'as pas écrit toi-même avant de laisser l'agent y travailler.

Garde Cursor à jour

Comme tout éditeur avec un agent intégré, Cursor a eu ses propres failles de sécurité, plusieurs liées à la confiance accordée aux espaces de travail et à MCP. Mets à jour dès qu'une nouvelle version sort et n'ouvre pas de projets d'origine douteuse avec l'exécution automatique activée.

Partie 2 : les failles que Cursor met dans ton code

Le modèle optimise pour que le code fonctionne, pas pour qu'il soit sûr. Voici les schémas qui reviennent le plus dans les apps écrites avec Cursor et comment les repérer :

• Secrets en dur. Pour qu'un exemple démarre vite, la clé finit dans le code ou dans une variable publique. Cherche sk_live, service_role, AKIA et -----BEGIN dans ton bundle. Plus de détails dans les secrets que ton app laisse fuir dans le navigateur.
• CORS ouvert et auth désactivée « pour que ça marche ». Face à une erreur, la suggestion typique est de refléter n'importe quelle origine ou de sauter la vérification de session. Ça marche sur le moment et ça laisse la porte ouverte en production.
• Endpoints qui font confiance au client. Des routes qui acceptent le user_id, le rôle ou le prix depuis le corps de la requête sans le vérifier côté serveur.
• Pas d'en-têtes de sécurité. Le code généré n'ajoute presque jamais CSP, HSTS ou X-Frame-Options ; vérifie avec le vérificateur d'en-têtes.
• Dépendances anciennes. Le modèle propose les versions qu'il connaît, pas les dernières. Lance npm audit avant de déployer.

Un bloc de règles de sécurité pour ton projet

La chose la plus rentable que tu puisses faire, c'est dire au modèle, une fois pour toutes, ce qu'il ne doit pas faire. Colle ceci dans .cursor/rules/security.mdc (ou dans .cursorrules) avec la règle configurée pour s'appliquer toujours. C'est en anglais parce que c'est la langue dans laquelle le modèle obéit le mieux :

# Security rules (always apply)
- Never hardcode API keys, tokens or passwords. Read them from
  environment variables on the server only.
- Never put secrets in variables prefixed NEXT_PUBLIC_, VITE_ or NUXT_PUBLIC_.
- Never disable authentication, authorization or Row Level Security
  to make something work. Fix the policy instead and explain why.
- CORS: allow only an explicit list of origins. Never reflect the
  request origin together with credentials.
- Validate input and authorize every API route on the server, even if
  the UI hides the action.
- Set security headers: CSP, HSTS, X-Frame-Options,
  X-Content-Type-Options, Referrer-Policy.
- Session cookies must be Secure, HttpOnly and SameSite=Lax.
- Add a dependency only when necessary, pinned to a maintained version.
- If a request conflicts with these rules, stop and explain the
  security trade-off before writing code.

Un prompt de revue avant de déployer

Avant chaque déploiement, ouvre un nouveau chat avec tout le projet en contexte et demande-lui : « Passe ce projet en revue comme un auditeur de sécurité avant le déploiement. Liste chaque secret qui atteint le code client, chaque route d'API sans vérification de session ou de permissions, chaque règle CORS ou RLS assouplie, les en-têtes de sécurité manquants et les cookies sans Secure, HttpOnly ou SameSite. Pour chaque résultat, indique le fichier, la ligne et la correction. Ne modifie pas encore le code. » Corrige ensuite les résultats un par un et redemande la revue.

Vérifie le résultat depuis l'extérieur

Le modèle passe en revue le code qu'il voit ; ce qui compte, c'est ce que voit un attaquant. Quand tu déploies, lance Scanaris sur l'URL publique : il détecte les secrets dans le JavaScript, le CORS permissif, les en-têtes et cookies mal configurés, les fichiers sensibles accessibles et les versions aux vulnérabilités connues, et te rend un prompt à coller dans Cursor pour chaque résultat. Laisse-le en surveillance et il te prévient quand une session de vibe coding rouvre quelque chose qui était déjà fermé. Pour la carte complète, lis le guide de sécurité des apps créées par IA et la checklist de lancement.

Questions fréquentes

Est-ce sûr d'utiliser Cursor avec du code d'entreprise ?

Avec le mode privé activé, les secrets exclus de l'indexation et sans coller de données réelles dans le chat, le risque est comparable à celui de n'importe quel outil cloud. Vérifie les politiques de ton entreprise et, si besoin, utilise le plan équipe pour imposer la configuration.

Le code écrit par Cursor est-il moins sûr que du code écrit à la main ?

Pas forcément, mais il échoue à des endroits prévisibles : secrets, permissions qui gênent et configuration que personne n'a demandée. Avec des règles claires et une revue avant de déployer, le résultat est souvent meilleur que la moyenne.

Que faire si l'agent a déjà exécuté quelque chose qu'il n'aurait pas dû ?

Fais tourner tout identifiant auquel il avait accès, vérifie l'historique git et celui du terminal pour voir ce qu'il a touché, et restreins l'exécution automatique avant de continuer.