Le .cursorignore protège-t-il ton fichier .env ? Ce que Cursor bloque vraiment

En partie. Cursor ignore déjà les fichiers .env* par défaut, et un fichier .cursorignore tient les chemins que tu y listes à l'écart d'Agent, de Tab, d'Inline Edit et des mentions @. Il ne couvre pas les commandes que l'agent lance dans son terminal ou via des outils MCP : un simple cat .env peut donc toujours faire atterrir tes secrets dans la conversation.

Au programme : ce que fait le fichier d'exclusion, les endroits exacts où il s'arrête, et une organisation de projet où l'agent n'a tout simplement rien de précieux à lire.

Ce que .cursorignore bloque

Le fichier se place à la racine de ton projet et utilise la syntaxe des motifs de .gitignore. D'après la page de référence de Cursor, tout ce qui correspond à ces motifs est tenu à l'écart :

• du code qu'Agent peut lire quand il répond ou modifie
• des complétions de Tab
• d'Inline Edit
• des fichiers que tu cites avec une mention @ dans le chat

Pour le .env en particulier, tu n'as peut-être rien à écrire. Cursor additionne trois sources d'exclusions : les motifs déjà présents dans ton .gitignore, une liste intégrée par défaut, et ton propre .cursorignore. La liste par défaut comprend .env*, les fichiers de verrouillage (lock files), les dossiers de gestion de versions comme .git/, les dossiers de dépendances comme node_modules/ et .venv/, les binaires, les archives et les fichiers multimédias.

Dans un projet classique, Tab ne fera donc pas d'autocomplétion à partir de ton .env, et une mention @ ne le joindra pas. Cette partie-là fonctionne.

Là où il s'arrête : le terminal et les outils MCP

La même page de documentation contient une phrase qui change la donne pour les secrets. Elle indique que le terminal et les outils des serveurs MCP utilisés par Agent ne peuvent pas bloquer l'accès au code régi par .cursorignore.

Le fichier d'exclusion décide de ce que Cursor lit de lui-même pour construire son contexte. Il n'a aucune prise sur ce que lit une commande shell. Quand l'agent essaie de déboguer une connexion à la base de données qui échoue, il peut lancer n'importe laquelle de ces commandes, et la sortie revient dans le chat comme un résultat d'outil ordinaire :

cat .env
printenv
env | grep -i key
node scripts/check-config.js   # if the script logs its config

Un serveur MCP qui a accès au système de fichiers est dans la même situation : il lit les fichiers avec son propre code, pas à travers le filtre de Cursor.

La documentation de Cursor ajoute aussi une mise en garde générale sur le fichier d'exclusion lui-même : même pour les fonctionnalités qu'il couvre, une protection complète n'est pas garantie, ce qu'elle attribue au caractère imprévisible des LLM. Le bon modèle mental : .cursorignore réduit les expositions accidentelles. Ce n'est pas un contrôle d'accès.

Les modes d'exécution et le sandbox, côté secrets

Qu'une commande de terminal s'exécute sans te demander ton avis dépend du mode d'exécution. Cursor en documente actuellement trois :

Auto-review est le mode recommandé, et sa documentation ne prend pas de gants : le classificateur peut se tromper dans les deux sens, et Auto-review n'est pas une frontière de sécurité.

Le sandbox mérite lui aussi une lecture attentive. Une commande exécutée dans le sandbox peut travailler dans ton projet, mais ne peut pas lire librement les fichiers protégés, écrire en dehors des chemins approuvés ni joindre n'importe quel hôte du réseau. Les chemins protégés listés par la documentation sont par exemple .git/config, .git/hooks, .vscode, .cursorignore et la configuration sensible de Cursor lui-même. Ton .env ne figure pas sur cette liste : une commande du sandbox lancée dans le dossier du projet peut donc toujours l'ouvrir.

Définis une liste d'exclusion globale une bonne fois pour toutes

Les fichiers propres à un projet sont faciles à oublier quand tu démarres un nouveau repo. Cursor propose aussi une liste d'exclusion globale dans ses réglages utilisateur, qui s'applique à tous les espaces de travail. Elle est vide par défaut. La documentation suggère des motifs de ce genre, et ça vaut la peine de les ajouter le jour où tu installes Cursor :

**/.env
**/.env.*
**/credentials.json
**/secrets.json
**/*.key
**/*.pem
**/id_rsa

Les mêmes motifs fonctionnent dans le .cursorignore d'un projet. Un piège de syntaxe signalé par la documentation : une négation ! ne peut pas réintégrer un fichier si son dossier parent a été exclu avec un joker comme public/*. Tu dois d'abord exclure explicitement le sous-dossier avant de réintégrer un fichier qui s'y trouve.

Garde les secrets de production hors du dossier du projet

Un fichier d'exclusion filtre un dossier qui contient toujours le secret. La solution la plus solide, c'est un dossier où il n'y a rien qui vaille la peine de fuiter.

1. Utilise des identifiants de développement en local. La plupart des fournisseurs séparent les identifiants de test de ceux de production. Stripe, par exemple, propose des clés en mode test et des clés restreintes (préfixe rk_) dont tu choisis les permissions ressource par ressource. Une clé de test limitée à une seule ressource qui fuite, c'est une corvée, pas un incident.
2. Garde les clés de production dans les réglages d'environnement de ton hébergeur. Elles sont injectées quand l'app tourne en production : les vraies valeurs n'ont jamais besoin de se trouver sur ton ordinateur portable.
3. Stocke des références plutôt que des valeurs. La CLI d'un gestionnaire de secrets peut résoudre des pointeurs au moment de l'exécution. Avec la CLI de 1Password, le fichier env contient des références comme op://vault/item/field, et op run lance ta commande dans un sous-processus où les vraies valeurs n'existent que pendant la durée de vie de ce processus :

$ cat .env.refs
STRIPE_SECRET_KEY=op://dev/stripe/secret_key
$ op run --env-file=.env.refs -- npm run dev

Si l'agent affiche .env.refs, il voit un chemin vers ton coffre, pas une clé. Garde en tête ce qui découle de cette conception : si la CLI est déjà connectée dans le terminal qu'utilise l'agent, l'agent peut lui aussi appeler op run. L'importance de ce point dépend de la façon dont la CLI reste autorisée, et de la durée.

Les commandes à lire avant de les approuver

Même avec un dossier propre, certaines commandes méritent une pause avant que tu cliques sur « approuver » :

• tout ce qui ouvre, affiche ou fouille des fichiers env : cat, head, less ou grep sur .env*
• printenv, env et export -p
• docker compose config et docker inspect, qui affichent la configuration résolue, valeurs d'environnement comprises
• les CLI de déploiement et d'hébergement qui listent ou téléchargent les variables d'environnement

Si tu utilises Auto-review, Cursor te permet d'écrire, en langage courant, des consignes d'autorisation et de blocage dans un fichier permissions.json. Ajouter « les commandes qui affichent des variables d'environnement ou lisent des fichiers env » à la liste de blocage est une couche supplémentaire raisonnable, à condition de te rappeler que le classificateur qui l'applique n'offre aucune garantie.

Le même chemin de fuite existe en dehors de l'éditeur. Un .env copié dans une image de conteneur reste lisible dans ses couches, ce que j'explique dans comment des secrets finissent dans les couches d'une image Docker.

Si une clé se retrouve dans le chat

Dès qu'un secret apparaît dans une conversation, il a été envoyé dans un prompt. Supprimer le chat après coup ne le récupère pas. Considère la clé comme exposée :

1. Fais-la tourner chez le fournisseur. Le tableau de bord de Stripe, par exemple, a une action « Rotate key » prévue pour ça.
2. Mets la nouvelle valeur partout où l'ancienne était utilisée, puis redéploie.
3. Parcours les journaux du fournisseur à la recherche d'activité que tu ne reconnais pas depuis l'exposition.
4. Vérifie que l'ancienne clé est réellement révoquée, et pas seulement remplacée dans ta configuration.

FAQ

Cursor lit-il mon fichier .env par défaut ?

La liste d'exclusion intégrée de Cursor comprend .env* : Agent, Tab, Inline Edit et les mentions @ ignorent donc ces fichiers, même sans .cursorignore. Les commandes que l'agent lance dans le terminal sont un chemin à part, et aucun fichier d'exclusion n'y empêche un cat .env.

Quelle est la différence entre .gitignore et .cursorignore ?

.gitignore indique à Git ce qu'il ne doit pas suivre, et Cursor le respecte aussi. .cursorignore ne concerne que Cursor : il utilise la même syntaxe de motifs pour exclure des chemins supplémentaires des fonctionnalités d'IA, y compris des fichiers que tu commites.

Le .cursorignore suffit-il à protéger mes clés d'API ?

Non. La documentation de Cursor elle-même dit qu'une protection complète n'est pas garantie et que le terminal et les outils MCP ne sont pas couverts. Combine-le avec des clés de test uniquement sur ta machine et l'habitude de lire toute commande qui touche aux variables d'environnement.

Sources

• Cursor docs, Ignore file
• Cursor docs, Run modes
• Stripe docs, API keys
• 1Password CLI, Load secrets into the environment