Protéger votre code source et votre environnement de développement est essentiel pour nous. Cette page décrit notre approche de la sécurité pour Cursor.

Veuillez nous signaler toute vulnérabilité potentielle par e-mail à security-reports@cursor.com.

Pour toute question liée à la sécurité, vous pouvez nous contacter à security@cursor.com.

Bien que plusieurs grandes organisations fassent déjà confiance à Cursor, veuillez noter que nous sommes encore en train de faire évoluer notre produit et de renforcer notre posture de sécurité. Si vous travaillez dans un environnement très sensible, vous devez être prudent lorsque vous utilisez Cursor (ou tout autre outil d’IA). Nous espérons que cette page vous donnera un aperçu de nos progrès et vous aidera à réaliser une évaluation adéquate des risques.

#Certifications et évaluations par des tiers

Cursor est certifié SOC 2 Type II. Veuillez consulter trust.cursor.com pour demander une copie du rapport.

Nous nous engageons à réaliser au moins une fois par an des tests d’intrusion menés par des tiers réputés. Veuillez consulter trust.cursor.com pour demander un résumé exécutif du dernier rapport.

#Sécurité de l'infrastructure

Nous dépendons des sous-traitants suivants, classés approximativement du plus critique au moins critique. Notez que les données de code sont envoyées à nos serveurs pour alimenter toutes les fonctionnalités d’IA de Cursor (voir la section Requêtes IA) et que les données de code des utilisateurs en mode de confidentialité (ancien mode) ne sont jamais conservées (voir la section Garantie du mode confidentialité).

Découvrez comment chaque mode affecte la manière dont les données sont envoyées et stockées :

*Cursor respecte les listes de blocage de modèles et n’enverra aucune requête à des modèles figurant sur une liste de blocage.

Aucune partie de notre infrastructure n’est située en Chine. Nous n’utilisons directement aucune entreprise chinoise comme sous-traitant et, à notre connaissance, aucun de nos sous-traitants ne le fait non plus.

Nous attribuons l’accès à l’infrastructure aux membres de l’équipe selon le principe du moindre privilège. Nous imposons l’authentification multifacteur pour AWS. Nous limitons l’accès aux ressources à l’aide de contrôles au niveau du réseau et de secrets.

#Sécurité côté client

Cursor est un fork du projet open source Visual Studio Code (VS Code), maintenu par Microsoft. Microsoft publie des avis de sécurité sur sa page de sécurité GitHub. Une version majeure de VS Code sur deux, nous fusionnons le code source amont 'microsoft/vscode' dans Cursor. Vous pouvez vérifier sur quelle version de VS Code votre version de Cursor est basée en cliquant sur "Cursor > About Cursor" dans l’application. S'il existe un correctif de sécurité de sévérité élevée dans la version amont de VS Code, nous l’isolerons avant la prochaine fusion et publierons une mise à jour immédiatement.

Notre application enverra des requêtes vers les domaines suivants pour communiquer avec notre backend. Si vous êtes derrière un proxy d'entreprise, veuillez mettre ces domaines sur liste blanche afin de garantir le bon fonctionnement de Cursor.

• 'api2.cursor.sh' : utilisé pour la plupart des requêtes API.

• 'api5.cursor.sh' : utilisé pour les requêtes d’agent de Cursor.

• 'api3.cursor.sh' : utilisé pour les requêtes Cursor Tab (HTTP/2 uniquement).

• 'repo42.cursor.sh' : utilisé pour l’indexation de bases de code (HTTP/2 uniquement).

• 'api4.cursor.sh', 'us-asia.gcpp.cursor.sh', 'us-eu.gcpp.cursor.sh', 'us-only.gcpp.cursor.sh' : utilisés pour les requêtes Cursor Tab en fonction de votre région (HTTP/2 uniquement).

• 'adminportal42.cursor.sh' : utilisé pour configurer le SSO et la vérification de domaine.

• 'marketplace.cursorapi.com', 'cursor-cdn.com', 'downloads.cursor.com', 'anysphere-binaries.s3.us-east-1.amazonaws.com' : utilisés pour les mises à jour du client et pour le téléchargement d’extensions depuis la place de marché des extensions.

Deux différences liées à la sécurité par rapport à VS Code sont à noter :

1. Workspace Trust est désactivé par défaut dans Cursor. Vous pouvez l'activer en définissant 'security.workspace.trust.enabled' sur 'true' dans vos paramètres Cursor. Il est désactivé par défaut pour éviter toute confusion entre le "Restricted Mode" de Workspace Trust et le "Privacy Mode" de Cursor, et parce que ses propriétés de confiance sont nuancées et difficiles à comprendre (par exemple, même avec Workspace Trust activé, vous n'êtes pas protégé contre les extensions malveillantes, uniquement contre les dossiers malveillants). Nous sommes ouverts aux retours de la communauté concernant l'opportunité de l'activer par défaut.

2. Signatures du code des extensions : Cursor ne vérifie pas les signatures des extensions téléchargées depuis la place de marché. VS Code a récemment commencé à le faire. En particulier, le paramètre 'extensions.verifySignature' est défini sur 'false' par défaut dans Cursor, mais sur 'true' dans VS Code. Si vous le définissez sur 'true' dans Cursor, vous verrez une fenêtre contextuelle indiquant que la vérification de la signature a échoué chaque fois que vous essayez de télécharger une extension. Nous espérons commencer à prendre en charge la vérification des signatures des extensions à moyen terme.

#Requêtes d’IA

Pour fournir ses fonctionnalités, Cursor envoie des requêtes d’IA à notre serveur. Cela se produit pour de nombreuses raisons différentes. Par exemple, nous envoyons des requêtes d’IA lorsque vous posez des questions dans le chat, nous envoyons des requêtes d’IA à chaque frappe afin que Cursor Tab puisse vous proposer des suggestions, et nous pouvons également envoyer des requêtes d’IA en arrière‑plan pour enrichir le contexte ou rechercher des bugs à vous afficher.

Une requête d’IA inclut généralement du contexte comme vos fichiers récemment consultés, votre historique de conversation et des extraits de code pertinents basés sur les informations du serveur de langage. Ces données de code sont envoyées à notre infrastructure sur AWS, puis au fournisseur de modèles de langage approprié pour l’inférence (Fireworks/OpenAI/Anthropic/Google). Notez que les requêtes passent toujours par notre infrastructure sur AWS, même si vous avez configuré votre propre clé API pour OpenAI dans les paramètres.

Nous n’avons actuellement pas la possibilité de router directement depuis l’application Cursor vers votre déploiement entreprise d’OpenAI/Azure/Anthropic, car la construction des prompts a lieu sur notre serveur et nos modèles personnalisés sur Fireworks sont essentiels pour offrir une bonne expérience utilisateur. Nous ne proposons pas encore d’option de déploiement de serveur auto‑hébergé.

#Indexation de la base de code

Cursor vous permet d’indexer sémantiquement votre base de code, ce qui lui permet de répondre aux questions avec le contexte de l’ensemble de votre code et d’écrire un meilleur code en se référant aux implémentations existantes. L’indexation de la base de code est activée par défaut, mais peut être désactivée dans les paramètres.

Notre fonctionnalité d’indexation de la base de code fonctionne comme suit : lorsqu’elle est activée, elle analyse le dossier que vous ouvrez dans Cursor et calcule un arbre de Merkle de hachages de tous les fichiers. Les fichiers et sous-répertoires spécifiés par '.gitignore' ou '.cursorignore' sont ignorés. L’arbre de Merkle est ensuite synchronisé avec le serveur. Toutes les 10 minutes, nous vérifions les divergences de hachage et utilisons l’arbre de Merkle pour déterminer quels fichiers ont changé et ne téléverser que ceux‑ci.

Sur notre serveur, nous découpons les fichiers en blocs et générons des embeddings, puis nous stockons ces embeddings dans Turbopuffer. Pour permettre le filtrage des résultats de recherche vectorielle par chemin de fichier, nous stockons avec chaque vecteur un chemin de fichier relatif obscurci, ainsi que l’intervalle de lignes auquel le bloc correspond. Nous stockons également l’embedding dans un cache sur AWS, indexé par le hachage du bloc, afin de garantir que réindexer une même base de code une seconde fois soit beaucoup plus rapide (ce qui est particulièrement utile pour les équipes).

Au moment de l’inférence, nous calculons un embedding, laissons Turbopuffer effectuer la recherche des plus proches voisins, renvoyons au client le chemin de fichier obscurci et l’intervalle de lignes, puis lisons localement ces blocs de fichier sur le client. Nous renvoyons ensuite ces blocs au serveur pour répondre à la question de l’utilisateur. Cela signifie que, pour les utilisateurs en mode de confidentialité, aucun code en clair n’est stocké sur nos serveurs ni dans Turbopuffer.

Quelques remarques :

• Pour empêcher l’envoi de fichiers spécifiques de votre base de code vers les serveurs de Cursor et leur inclusion dans les requêtes d’IA, ajoutez un fichier '.cursorignore' à votre base de code qui répertorie les fichiers et répertoires devant être exclus. Cursor fera tout son possible pour empêcher que ces fichiers soient exposés dans une quelconque requête.

• Détails sur l’obscurcissement des chemins de fichier : le chemin est séparé par '/' et '.' et chaque segment est chiffré avec une clé secrète stockée sur le client et un nonce déterministe court de 6 octets. Cela révèle des informations sur la hiérarchie des répertoires et entraînera quelques collisions de nonce, mais masque la plupart des informations.

• Inversion des embeddings : des travaux académiques ont montré qu’il est possible, dans certains cas, d’inverser des embeddings. Les attaques actuelles reposent sur l’accès au modèle et sur l’insertion de chaînes courtes dans de grands vecteurs, ce qui nous amène à penser qu’une telle attaque serait relativement difficile à mener ici. Cela dit, il est tout à fait possible pour un adversaire qui parviendrait à s’introduire dans notre base de données vectorielle d’apprendre certaines choses sur les bases de code indexées.

• Lorsque l’indexation de la base de code est activée dans un dépôt Git, nous indexons également l’historique Git. Plus précisément, nous stockons les SHAs de commit, les informations de parenté et les noms de fichiers obscurcis (comme ci‑dessus). Pour permettre le partage de la structure de données entre les utilisateurs d’un même dépôt Git et d’une même équipe, la clé secrète servant à obscurcir les noms de fichiers est dérivée des hachages du contenu des commits récents. Les messages de commit et le contenu des fichiers ou leurs diffs ne sont pas indexés.

• Notre fonctionnalité d’indexation est souvent soumise à une forte charge, ce qui peut entraîner l’échec de nombreuses requêtes. Cela signifie que, parfois, les fichiers devront être téléversés plusieurs fois avant d’être entièrement indexés. Concrètement, si vous vérifiez le trafic réseau vers 'repo42.cursor.sh', il est possible que vous constatiez une utilisation de bande passante supérieure à ce à quoi vous vous attendiez.

#Garantie du mode de confidentialité

Le mode de confidentialité peut être activé dans les paramètres ou par un administrateur d’équipe. Lorsqu’il est activé, nous garantissons que les données de code ne sont jamais stockées par nos fournisseurs de modèles ni utilisées pour l’entraînement. Le mode de confidentialité peut être activé par n’importe qui (utilisateur gratuit ou Pro) et est, par défaut, appliqué de façon forcée à tout utilisateur membre d’une équipe.

Nous prenons la garantie du mode de confidentialité très au sérieux. Plus de 50 % de tous les utilisateurs de Cursor ont le mode de confidentialité activé.

Chaque requête envoyée à notre serveur inclut un en-tête 'x-ghost-mode', contenant une valeur booléenne indiquant si l’utilisateur est en mode de confidentialité. Pour éviter de traiter accidentellement un utilisateur en mode de confidentialité comme un utilisateur non soumis au mode de confidentialité, nous partons toujours du principe qu’un utilisateur est en mode de confidentialité si l’en-tête est manquant.

Toutes les requêtes vers notre serveur arrivent d’abord sur un proxy, qui décide quel service logique doit traiter la requête (par exemple le « chat service » ou le « Cursor Tab service »). Chaque service logique existe en deux réplicas quasi identiques : un replica qui gère les requêtes en mode de confidentialité, et un replica qui gère les requêtes hors mode de confidentialité. Le proxy vérifie la valeur de l’en-tête 'x-ghost-mode' et envoie la requête au replica approprié. Les replicas eux-mêmes vérifient également l’en-tête, par redondance. Par défaut, toutes les fonctions de journalisation des replicas en mode de confidentialité sont sans effet (no-op), sauf lorsqu’elles portent un suffixe comme 'infoUnrestricted', pour lequel nous vérifions soigneusement qu’aucune donnée de code potentielle ni aucun prompt n’y soit jamais attaché. Pour les requêtes qui déclenchent des tâches en arrière-plan, nous disposons de la même façon de files d’attente parallèles et de replicas de workers pour le mode de confidentialité et pour le mode hors confidentialité. Cette infrastructure parallèle nous donne confiance dans notre garantie du mode de confidentialité et dans sa résilience face aux erreurs ou bugs accidentels.

Pour l’application du mode de confidentialité au niveau des équipes, chaque client interroge le serveur toutes les 5 minutes pour vérifier si l’utilisateur fait partie d’une équipe qui impose le mode de confidentialité. Le cas échéant, ce réglage remplace la configuration de mode de confidentialité du client. Pour éviter les cas où le ping de mode de confidentialité du client échoue pour une raison quelconque, notre serveur vérifie également, dans le chemin critique, si l’utilisateur fait partie d’une équipe qui impose le mode de confidentialité et, le cas échéant, traite la requête comme si elle était en mode de confidentialité même si l’en-tête indique le contraire. Sur les services sensibles à la latence, nous mettons cette valeur en cache pendant 5 minutes, et en cas de défaut de cache, nous supposons que l’utilisateur est en mode de confidentialité. En résumé, cela signifie que lorsqu’un utilisateur rejoint une équipe, il a la garantie d’être en mode de confidentialité au plus tard 5 minutes après avoir rejoint l’équipe.

#Suppression de compte

Vous pouvez supprimer votre compte à tout moment dans le tableau de bord des paramètres (cliquez sur « Advanced », puis sur « Delete Account »). Cela supprimera toutes les données associées à votre compte, y compris tout code indexé. Nous garantissons la suppression complète de vos données sous 30 jours (nous supprimons immédiatement les données, mais certaines de nos bases de données et solutions de stockage cloud conservent des sauvegardes pendant au maximum 30 jours).

À noter que si certaines de vos données ont été utilisées pour l’entraînement de modèles (ce qui ne pourrait se produire que si vous n’étiez pas en mode de confidentialité à ce moment‑là), nos modèles déjà entraînés ne seront pas réentraînés immédiatement. En revanche, aucun futur modèle ne sera entraîné à partir de vos données, puisque ces données auront été supprimées.

#Divulgation de vulnérabilités

Si vous pensez avoir découvert une vulnérabilité dans Cursor, veuillez nous envoyer un rapport à l'adresse security-reports@cursor.com.

Nous nous engageons à accuser réception des rapports de vulnérabilité dans un délai de 5 jours ouvrables et à les traiter dès que possible. Les incidents critiques seront communiqués par e-mail à tous les utilisateurs.