// docs / security guides / pre-ship checklist

La checklist de sécurité vibe coding : 44 items avant le déploiement

Une liste de contrôle pratique et organisée par phases pour les applications créées avec Cursor, Claude Code, Lovable, Bolt, v0, Replit et Windsurf. Chaque élément est exploitable en moins de cinq minutes. Parcourez-le avant de passer en production, puis à nouveau avant chaque version majeure. Les éléments sont regroupés en sept catégories (secrets, base de données, authentification, en-têtes, tiers, déploiement, surveillance) et étiquetés avec la phase de déploiement à laquelle ils s'appliquent.

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 (8 éléments)

Les clés codées en dur sont la découverte la plus courante dans les applications codées par ambiance. Huit éléments pour les éloigner :

PRE — Audit NEXT_PUBLIC_ env vars. Tout ce qui porte le préfixe NEXT_PUBLIC_ est livré dans les bundles clients. S'il s'agit d'une clé Supabase service_role (décode en JWT avec "role":"service_role"), supprimez-la et acheminez-la via un client serveur uniquement (src/lib/supabase/service.ts avec import 'server-only').
PRE — Grep for hardcoded provider keys. Source de recherche pour sk_live_, pk_live_, STRIPE_SECRET, sk-ant-, sk-, AIza, AKIA et JWT- chaînes de recherche (eyJ). Déplacez chaque hit dans .env.local et référencez-le via process.env.* côté serveur uniquement.
PRE — Verify .gitignore. Confirmez que .env*.local, .npmrc, .yarnrc et tous les fichiers d'informations d'identification spécifiques au fournisseur sont ignorés. Exécutez git ls-files via les modèles de votre fournisseur pour trouver tout ce qui a déjà été validé.
PRE — Scan the built bundle. Exécutez npm run build, puis grep .next/static et toute sortie dist/ pour les mêmes modèles. Si une clé atteint le bundle, le développeur n'a jamais eu de séparation d'environnement propre.
DEPLOY — Set secrets per environment. Vercel : Paramètres → Variables d'environnement, chacune étant étendue à Production / Aperçu / Développement. Ne partagez jamais sk_live_* avec l'environnement Preview. Utilisez le stockage env-var chiffré de Vercel, et non les secrets de flux de travail en ligne.
DEPLOY — Disable build-log secret echo. Quelques CI configurations echo variables d'environnement pendant la construction. Auditez vos flux de travail d'actions vercel.json, GitHub ou vos paramètres de pages Cloudflare pour tout echo $SECRET qui pousserait la valeur dans les journaux de build publics.
POST — Run a passive scan. Le niveau Free de FixVibe couvre ceci : collez le URL déployé, attendez environ 20 s, recherchez les résultats secrets.*. Le contrôle secrets.browser-storage détecte les clés qui ont atterri dans localStorage ou sessionStorage via une mauvaise utilisation du SDK.
POST — Rotate any key that ever shipped. Si une clé est restée dans un bundle public pendant quelques minutes paires, considérez-la comme compromise. Faites pivoter Supabase les clés de rôle de service via le tableau de bord, régénérez Stripe les clés restreintes, révoquez les clés Anthropic / OpenAI / Google via leurs consoles.

Contrôle d'accès à la base de données : RLS et règles Firestore (6 éléments)

BaaS les valeurs par défaut sont volontairement permissives, donc le premier didacticiel fonctionne. Production a besoin de politiques explicites.

PRE — Force RLS on every public.* table. Dans Supabase : chaque table doit avoir ALTER TABLE ... ENABLE ROW LEVEL SECURITY et FORCE ROW LEVEL SECURITY. Force compte : sans cela, Postgres contourne RLS pour les propriétaires de tables.
PRE — Write a policy per (table, role, action). Minimum : une stratégie SELECT qui rejoint auth.uid(). Mieux : séparez les politiques INSERT / UPDATE / DELETE afin qu'un UPDATE ne puisse pas introduire clandestinement des user_id modifications qui redirigent la propriété.
PRE — Replace default Firebase rules. Les règles du mode test par défaut sont allow read, write: if true;. Remplacer par des règles liées à l'authentification par collection : match /users/{userId} par allow read, write: if request.auth.uid == userId;
PRE — Lint migrations in CI. Exécutez supabase db lint ou un équivalent avant de fusionner. CI devrait échouer la construction si un CREATE TABLE public.* ne dispose pas d'une stratégie RLS correspondante.
DEPLOY — Confirm RLS survived deploy. Revérifiez dans Supabase Studio après le déploiement : Tables → chaque ligne → RLS la bascule est ON. Production les migrations de bases de données devancent parfois les fichiers de stratégie ; vérifiez que la politique est active.
POST — Run an active scan against a verified domain. La vérification active baas.supabase-rls écrit dans une petite ligne de départ à l'aide de la touche anon et signale si l'écriture a réussi - i.e. RLS n'est pas réellement appliqué.

Authentification et sessions (7 éléments)

Les bogues d'authentification dans les applications codées AI- ont tendance à être subtils : un par un dans la vérification des jetons, un indicateur HttpOnly manqué, un getSession() là où il devrait y avoir un getUser().

PRE — Replace getSession() with getUser(). getSession() lit le cookie et lui fait confiance ; getUser() vérifie avec le backend Supabase. Sur les routes du serveur, utilisez toujours getUser().
PRE — Confirm token expiry. Les jetons Magic-link, de réinitialisation de mot de passe et de vérification de courrier électronique nécessitent une expiration forcée par le serveur. Les liens magiques Supabase par défaut expirent après 1 heure – ne remplacez pas cela par un nombre plus élevé sans raison réelle.
PRE — Verify JWT aud and exp. Si vous décodez les jetons manuellement n'importe où, vérifiez les deux affirmations. Mieux : utilisez le getUser() de SDK qui le fait pour vous.
PRE — Audit cookie flags. Les cookies de session personnalisés doivent être Secure; HttpOnly; SameSite=Lax (ou Strict pour les flux non-OAuth). Aucun matériel de session dans localStorage.
PRE — Validate the next redirect param. Le paramètre de requête next après la connexion doit commencer par / et non par // (redirection ouverte vers attacker.example). Rejetez tout le reste côté serveur.
POST — Test logout. Connectez-vous, déconnectez-vous, inspectez les cookies (DevTools → Application → Cookies). Le cookie de session doit être effacé sur la même réponse. Si cela persiste, le gestionnaire de déconnexion ne détruit pas réellement l'état côté serveur.
POST — Active probe. Les vérifications active.auth-flow et active.account-enumeration font apparaître des limites d'authentification brisées : réponses différentes sur "l'utilisateur existe" et "mot de passe incorrect", limite de débit manquante lors de la connexion, jetons de réinitialisation non signés.

HTTP en-têtes de sécurité et politique de sécurité du contenu (6 éléments)

Les en-têtes sont le durcissement le moins cher de tout le pipeline et le plus systématiquement ignoré par codegen.

PRE — Ship a real CSP. Minimum : script-src 'nonce-{NONCE}' 'strict-dynamic'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'. Non 'unsafe-inline' dans script-src. Next.js applique automatiquement le nom occasionnel lorsque le middleware définit l'en-tête de requête x-nonce.
PRE — Add the legacy three. X-Content-Type-Options: nosniff, X-Frame-Options: DENY (ou comptez sur CSP frame-ancestors seul), Strict-Transport-Security: max-age=31536000; includeSubDomains.
PRE — Tighten Referrer-Policy. Par défaut, strict-origin-when-cross-origin convient à la plupart des applications. N'expédiez pas unsafe-url ou pas d'en-tête du tout.
PRE — Replace Access-Control-Allow-Origin: *. Merci pour ça. Remplacez par une liste blanche d'origine explicite. Partout où se trouve * à côté de credentials: include, le navigateur refusera la demande – mais cela ne constitue pas une défense contre un backend mal configuré.
DEPLOY — Verify headers post-deploy. Ouvrez DevTools → Réseau → cliquez sur votre document racine → onglet En-têtes. CSP, HSTS, X-Frame-Options, X-Content-Type-Options doivent être présents. CSP ne doit pas avoir 'unsafe-inline' dans script-src.
POST — Run headers.security-headers. La vérification passive des en-têtes signale chaque en-tête manquant avec des conseils de correction de la plate-forme de déploiement (Vercel vercel.json, Cloudflare Pages _headers, Netlify _headers, Next.js middleware).

Intégrations tierces et APIs (5 éléments)

Chaque script que vous incluez est une exemption CSP et une surface potentielle de chaîne d'approvisionnement. Traitez les tiers comme faisant partie de votre limite de confiance.

PRE — Reverse-proxy analytics where possible. PostHog, Plausible, Umami prennent tous en charge le proxy via votre propre domaine (e.g. /api/posthog). Cela maintient connect-src sur la même origine et survit aux bloqueurs de publicités.
PRE — CSP-allowlist the rest. Pour Google Analytics, Stripe.js, Sentry, Intercom, GTM, etc., ajoutez les origines de chaque fournisseur à la directive CSP correspondante (script-src pour les chargeurs, connect-src pour la télémétrie, frame-src pour les iframes, img-src pour les pixels).
PRE — Use Stripe Checkout, not raw card forms. Stripe Checkout est une redirection de niveau supérieur ; aucune entrée CSP n'est nécessaire pour le script. La surface hébergée PCI vit entièrement sur le domaine de Stripe. Roulez le vôtre seulement si vous avez une bonne raison.
PRE — Lock package-lock.json in CI. Exécutez npm ci (et non npm install) dans les versions de production. Auditez les dépendances avec npm audit ou Snyk avant chaque version.
POST — Watch discovery.tech-fingerprint. La découverte passive de la pile technologique fait apparaître les versions de bibliothèque visibles par un robot. Si vous expédiez un EOL React, jQuery ou Bootstrap, FixVibe le signale et crée des liens vers des CVE connus.

Hygiène et infrastructure de déploiement (8 éléments)

La manière dont vous déployez compte autant que ce que vous déployez. AI-Les applications codées bénéficient particulièrement du renforcement explicite du déploiement.

PRE — Disable x-powered-by. Dans next.config.js : poweredByHeader: false. Supprime un signal de divulgation de version gratuit.
PRE — Confirm middleware lives at src/middleware.ts. Avec la disposition du répertoire src/, Next.js ignore un middleware.ts au niveau racine. Un middleware égaré ne parvient pas à définir CSP / en-têtes d'authentification / limites de débit.
PRE — Sanity-check Vercel deployment protection. Production doit être publique ; L'aperçu doit être protégé par mot de passe ou limité aux membres de l'organisation. discovery.platform-vercel rapporte la surface.
PRE — Block dotfile and config probes at the edge. Ajoutez une règle de réécriture ou de refus pour les modèles /.env, /.git/*, /.aws/*, /.next/trace. Vercel renvoie 403 pour beaucoup d'entre eux par défaut ; recoupement.
DEPLOY — Separate environments. Production, Prévisualisation, Développement. Chacun a son propre ensemble de secrets. Les touches actives n'atteignent jamais l'aperçu, le mode test Stripe n'atteint jamais Production.
DEPLOY — Enable Vercel Web Application Firewall. Pro et les forfaits Entreprise incluent WAF avec des règles gérées. Cloudflare Pages dispose du mode Combat de robots. Les deux réduisent les abus liés aux scanners automatisés et la charge de pulvérisation de mots de passe.
POST — Verify TLS configuration. SSL Labs ou testssl.sh par rapport à votre domaine de production. TLS 1.2 minimum, préférez TLS 1.3, pas de chiffrements faibles, HSTS préchargement éligible.
POST — Confirm health-check endpoints are minimal. Un /api/health doit renvoyer 200 OK sans corps. Ne faites pas écho à l'environnement, ne créez pas de hachage ou ne déployez pas d'horodatage sans authentification.

Surveillance et nouvelle analyse continues (4 éléments)

La sécurité n’est pas un audit unique avant expédition. La dérive se produit à chaque déploiement.

Verify your production domain in FixVibe. Dashboard → Domains → DNS TXT ou HTTP vérification du fichier. Cela débloque les nouvelles analyses programmées, les sondages actifs et la surveillance des menaces en direct.
Schedule passive re-scans. Pro les plans prennent en charge une cadence de 3 heures ; Unlimited prend en charge une cadence de 6 heures. Chaque analyse planifiée qui fait apparaître une nouvelle découverte déclenche un e-mail (et un webhook si vous en avez un câblé).
Wire outbound webhooks. Account → Webhooks → ajoutez un point de terminaison HTTPS, abonnez-vous à scan.completed + finding.created + scan.active_api.first_used. Accédez à Slack / Discord / PagerDuty.
Enable live threat monitoring on Unlimited. Diffs des journaux de transparence des certificats, DNS modifications, JS fuites de secrets de bundle, listes d'informations sur les menaces — déclenchés au moment où ils sont détectés, et non lors de la prochaine analyse planifiée.

Prochaines étapes

Vous voulez connaître le contexte pédagogique expliquant pourquoi ces éléments sont importants ? Lisez AI-generated code security scanning. Vous voulez des extraits de code concrets pour chaque étape de durcissement ? Voir How to secure an app built with AI coding tools.