// docs / security guides / cursor checklist

Checklist de sécurité Cursor : 28 items avant déploiement

Construire avec Cursor ? Les fonctionnalités de saisie semi-automatique, de mode Composer et d'agent de Cursor sont exceptionnellement puissantes et créent des angles morts de sécurité prévisibles. Cette liste de contrôle cible les modèles spécifiques à Cursor : l'intégration de clés de rôle de service, les fichiers entiers générés par Composer sans révision, les commandes de terminal en mode agent et le fichier <code>.cursorrules</code> comme premier garde-fou de sécurité. 28 éléments couvrant les secrets, la base de données, l'authentification, les en-têtes, le déploiement et les pièges spécifiques à Cursor.

PRE = pré-déploiement (vérifiez votre source). DEPLOY = au moment du déploiement. POST = vérification post-déploiement. Les éléments font référence à FixVibe et vérifient les identifiants sous la forme category.check-id, le cas échéant.

Secrets et clés API (5 éléments)

La saisie semi-automatique de Cursor est formée sur du code open source où les secrets sont courants. Le modèle les suggère librement, surtout après une tentative d'authentification ratée.

PRE — Write security rules into .cursorrules. Ajoutez une ligne : "N'incluez jamais SUPABASE_SERVICE_ROLE_KEY, sk_live_* ou toute variable d'environnement commençant par un acronyme de fournisseur dans le code côté client. Utilisez toujours les importations serveur uniquement." Cursor lit .cursorrules et en tient compte dans chaque suggestion.
PRE — Audit Composer-generated files. Lorsque le Composer de Cursor crée un fichier entier (en particulier les gestionnaires d'authentification), examinez-le ligne par ligne. Composer intègre parfois des variables d'environnement qui doivent rester uniquement sur le serveur. Recherchez NEXT_PUBLIC_ ou des références directes aux clés de service dans les importations de composants.
PRE — Reject auto-imports of service clients into client components. Si Composer importe import { supabase } from '@/lib/supabase/service' dans un fichier React, supprimez-le immédiatement et acheminez-le plutôt via un point de terminaison API. Les importations uniquement sur le serveur sont explicitement marquées : ne les ignorez pas.
PRE — Scan Agent-mode commits. Le mode Agent exécute les commandes du terminal et peut effectuer une validation directement. Auditez git log --oneline -20 et git diff HEAD~5 pour vous assurer qu'aucune chaîne d'apparence secrète n'a été validée lors de l'exécution d'un agent.
POST — Run secrets.browser-storage. Analyse passive sur le URL déployé. Si une clé de service apparaît dans le bundle JS, faites-la pivoter immédiatement – la saisie semi-automatique de Cursor l'a probablement intégrée.

Contrôle d'accès à la base de données (4 éléments)

Composer génère souvent un code d'authentification fonctionnel mais ignore RLS — le moment « ça marche » aveugle les gens sur l'application manquante de la politique.

PRE — Force Cursor to generate migrations with RLS. Dans .cursorrules : "Chaque migration CREATE TABLE public.* doit inclure ALTER TABLE ... ENABLE ROW LEVEL SECURITY et FORCE ROW LEVEL SECURITY." Demandez ensuite à Composer de générer la migration.
PRE — Review Composer-generated policies. Composer écrit parfois des stratégies sans vérifier auth.uid(). Les politiques comme allow select on public.items sans clause using sont dangereusement larges. Exiger une correspondance user_id.
DEPLOY — Confirm FORCE ROW LEVEL SECURITY is live. Ouvrez Supabase Studio, vérifiez la bascule RLS de chaque table. Si la migration de Composer avait ENABLE mais a oublié FORCE, les propriétaires de table (vos migrations) contournent RLS. C'est une véritable lacune.
POST — Run the baas.supabase-rls active check. Il tente une écriture avec la touche anon. S'il réussit, RLS n'est pas réellement appliqué – il manque probablement le mot-clé FORCE.

Authentification et sessions (4 éléments)

Cursor génère rapidement des flux d'authentification mais manque souvent la subtile validation côté serveur qui assure la sécurité des jetons.

PRE — Ensure all auth routes use getUser(). Recherchez getSession() dans vos itinéraires API et remplacez-le par await supabase.auth.getUser(). getSession() lit un cookie non vérifié ; getUser() valide avec le backend Supabase.
PRE — Check Composer auth handlers for token expiry. Les jetons Magic-link doivent être appliqués par le serveur expires_at. La valeur par défaut de Supabase est de 1 heure — ne demandez pas à Cursor de la remplacer sans raison réelle.
PRE — Audit the sign-in redirect guard. La redirection du paramètre de requête next après la connexion doit être validée : doit commencer par /, jamais //. Le compositeur saute parfois cela. Ajoutez-le manuellement s'il est manquant.
POST — Test logout server-side state destruction. Connectez-vous, déconnectez-vous, inspectez les cookies (DevTools → Application → Cookies). Le cookie de session doit être effacé immédiatement. Si cela persiste, le gestionnaire de déconnexion ne détruit pas l'état.

HTTP en-têtes de sécurité et CSP (3 éléments)

Cursor génère rarement un middleware par défaut. Si vous ne le demandez pas explicitement, CSP et HSTS ne sont généralement pas là.

PRE — Demand CSP in .cursorrules. Ajouter : "Générez un src/middleware.ts avec Content-Security-Policy. Utilisez un nom occasionnel pour script-src, pas unsafe-inline." Demandez ensuite à Cursor de le générer. Sans cet indice, le middleware est ignoré.
PRE — Verify src/middleware.ts exists. Avec la disposition du répertoire src/, Next.js ne récupère que src/middleware.ts. Un middleware.ts au niveau racine est ignoré en silence. Si CSP n'atteint pas, vérifiez que le fichier est au bon endroit.
POST — Run headers.security-headers. L'analyse passive signale l'absence de CSP, HSTS, X-Frame-Options, X-Content-Type-Options. Ouvrez le rapport et suivez les instructions de correctif pour votre plateforme de déploiement.

Hygiène de déploiement (5 éléments)

Les applications Cursor atterrissent souvent sur Vercel, qui a de bonnes valeurs par défaut mais nécessite un renforcement explicite pour la limite build/deploy.

DEPLOY — Check Vercel env-var scoping. Paramètres → Variables d'environnement → chaque secret doit être limité à Production uniquement. Ne partagez jamais sk_live_* avec Preview ou Development.
DEPLOY — Disable build-log secret echo. Si votre workflow d'actions vercel.json ou GitHub comporte echo $SECRET, supprimez-le. Les journaux de build sont archivés publiquement ; les secrets des journaux sont compromis.
DEPLOY — Use Vercel's managed secrets, not inline workflow vars. Paramètres de Vercel → Les variables d'environnement sont chiffrées au repos. GitHub Les secrets des actions valent mieux que rien, mais sont conçus pour CI, et non pour l'intégration de la plateforme de déploiement.
POST — Verify CSP nonce on the deployed preview. Ouvrez un lien d'aperçu Vercel dans le navigateur, ouvrez DevTools → Réseau → la réponse racine HTML. L'en-tête CSP doit être présent et inclure 'strict-dynamic' avec un nom occasionnel unique par requête.
POST — Rotate any key that ever shipped, even to Preview. Si une clé atteint le bundle de production pendant même 10 minutes, elle est compromise. Faites pivoter immédiatement.

Cursor pièges spécifiques (4 éléments)

Modèles propres au flux de travail de Cursor qui créent des risques de sécurité :

Agent mode auto-fixes propagate old patterns. Si vous demandez à l'agent de "corriger les erreurs d'authentification", il peut régénérer le même fichier d'authentification plusieurs fois, en insérant à chaque fois la même clé de service si elle se trouve dans le contexte de base de code. Nettoyez d'abord l'original, puis demandez à l'agent de le réparer.
L'indexation @codebase de Cursor Index leaks intent. Cursor est puissante, mais si votre répertoire .cursor est exposé (S3 mal configuré, historique git), l'index révèle votre architecture et vos modèles secrets. Gardez .cursor local.
Composer mode loses context between files. Chaque fichier généré par Composer est récent. Si vous lui demandez de générer un fichier client, puis une route API, ils peuvent utiliser différentes configurations client Supabase. Examinez les deux et assurez-vous qu’ils correspondent à votre architecture.
Autocomplete bias toward "working" over "secure". Cursor suggère le code le plus rapide qui passe votre contexte actuel. Si votre test contient NEXT_PUBLIC_SERVICE_KEY, la saisie semi-automatique s'en souvient et le suggère à nouveau. Nettoyez les appareils de test avant de partager le code avec le modèle.

Prochaines étapes

Une fois que vous avez verrouillé les modèles spécifiques à Cursor, vérifiez par recoupement avec general vibe coding security checklist (44 éléments), puis avec step-by-step hardening. Consultez également le Claude Code checklist si vous mélangez des outils.