vibe-coding-security

Vous êtes à 30 minutes du lancement. Stop. Exécutez ceci d'abord.

La seule vulnérabilité Lovable RLS (CVE-2025-48757, 2025, CVSS 9.3) a exposé plus de 170 applications en production. Moltbook a exposé 1,5 million de jetons API en février 2026 — interrogeables avec un simple curl. Ce n'étaient pas des cas marginaux. C'étaient des lancements grand public.

Cette checklist regroupe 69 éléments spécifiques et testables couvrant l'authentification, les secrets, les API, les bases de données, le frontend, l'IA/LLM, l'outillage des agents et le déploiement. Si vous ne pouvez pas cocher les 69, ne lancez pas.

Authentification (8 éléments)

• 1. La sécurité au niveau des lignes (RLS) de la base de données est activée sur chaque table de votre base de données.
• 2. Des politiques RLS existent pour chaque table et chaque rôle (anon, authenticated, service_role).
• 3. Les jetons JWT sont validés côté serveur sur chaque route API protégée (ne faites jamais confiance au frontend pour valider l'authentification).
• 4. Les sessions sont renouvelées ou invalidées après connexion (protection CSRF + fixation de session).
• 5. Les liens magiques (authentification sans mot de passe) sont à usage unique, expirent en moins de 15 minutes et sont liés à l'adresse IP ou à l'empreinte de l'appareil de l'utilisateur.
• 6. Vous ne pouvez pas mettre à jour ni supprimer des utilisateurs, commandes ou enregistrements sensibles en vous basant uniquement sur des ID fournis par l'utilisateur. Test : essayez de modifier l'enregistrement d'un autre utilisateur en changeant l'ID dans la requête.
• 7. Les jetons CSRF sont validés sur les requêtes modifiant l'état (POST, PUT, DELETE) via un cookie à double soumission ou SameSite=Strict.
• 8. Les cookies de session ont les attributs HttpOnly, Secure et SameSite=Strict définis.

Secrets et environnement (7 éléments)

• 9. Aucun secret dans les variables NEXT_PUBLIC_*, les fichiers .env Vue/React, ni de chaînes codées en dur. Recherchez NEXT_PUBLIC_ et auditez toutes les variables.
• 10. .env, .env.local, .env.*.local sont dans .gitignore et jamais commités. Vérifiez l'historique git : git log --all -p | grep -i "api_key\|secret".
• 11. La clé service_role de Supabase est UNIQUEMENT dans le .env côté serveur (Node, Python, Go, etc.), jamais dans les bundles frontend ni .env.local. La clé service_role contourne entièrement la RLS — une seule fuite donne un accès complet en lecture/écriture à chaque table.
• 12. Clés Stripe : clé publique dans NEXT_PUBLIC_*, clé secrète côté serveur uniquement, signature du webhook vérifiée.
• 13. Les clés API OpenAI, Anthropic et xAI ne sont jamais dans le code frontend ; toujours relayées via votre API.
• 14. Aucune clé API, URL de base de données ou identifiant codé en dur dans le code source (y compris les commentaires et le code inutilisé).
• 15. Les secrets sont renouvelés après le lancement ou s'ils ont été exposés dans l'historique du code source.

Durcissement des API (10 éléments)

• 16. La limitation de débit est active sur /api/auth/*, /api/login, /api/register. Test : 100 requêtes/minute doivent renvoyer une erreur 429.
• 17. Toutes les entrées utilisateur vers /api/* sont validées avec Zod, Yup ou similaire avant de toucher la base de données. Aucun req.body brut transmis aux requêtes.
• 18. Pas d'assignation massive : l'utilisateur ne peut pas définir admin=true, role=admin ou d'autres champs sensibles en les envoyant en POST.
• 19. Les signatures de webhook sont vérifiées (comparez l'en-tête de signature HMAC-SHA256 à la valeur attendue à l'aide d'une comparaison à temps constant).
• 20. CORS n'est pas défini sur *. Les origines autorisées sont codées en dur et n'incluent pas localhost en production.
• 21. Les requêtes SQL utilisent uniquement des instructions paramétrées. Aucune concaténation d'entrées utilisateur dans le SQL.
• 22. Les requêtes NoSQL (MongoDB, Firebase, etc.) ne concatènent pas les entrées utilisateur dans les filtres ou sélecteurs.
• 23. Les téléversements de fichiers sont validés (type MIME + taille du fichier), stockés hors de la racine web et renommés pour empêcher le path traversal.
• 24. Les redirections après connexion sont sur liste blanche. Impossible de rediriger vers un domaine externe via une redirection ouverte.
• 25. L'API n'effectue pas de requêtes externes non validées. Assurez-vous que les URL utilisées dans les requêtes côté serveur proviennent de votre liste d'autorisation, pas des entrées utilisateur (prévention SSRF).

Base de données (6 éléments)

• 26. La RLS est APPLIQUÉE sur toutes les tables. Le rôle anon ne peut pas faire de SELECT/INSERT/UPDATE/DELETE sur une table sans une politique explicite l'y autorisant.
• 27. Le rôle public anon n'a aucune permission par défaut. Les politiques n'accordent que le strict nécessaire. Lecture seule sur les listes publiques, jamais d'écriture.
• 28. La clé service-role est utilisée UNIQUEMENT dans le code côté serveur. Vérifiez : grep -r "service_role" src/. Elle ne doit renvoyer aucun résultat dans les fichiers frontend.
• 29. Isolation des données utilisateur : les requêtes filtrent toujours par auth.uid() ou team_id. Aucune requête ne renvoie tous les enregistrements de tous les utilisateurs.
• 30. Les suppressions douces (drapeau is_deleted) ou les tables d'archivage empêchent la perte accidentelle de données. Les suppressions définitives sont journalisées avec acteur + horodatage.
• 31. Des sauvegardes de base de données existent et sont testées. Vous avez vérifié que vous pouvez restaurer à partir d'une sauvegarde avant ce lancement.

Frontend (8 éléments)

• 32. Aucun dangerouslySetInnerHTML ou innerHTML sans assainissement DOMPurify. Auditez chaque instance dans le codebase.
• 33. Toutes les dépendances npm/pip/gem sont analysées à la recherche de CVE connues. Exécutez npm audit, pnpm audit ou npx osv-scanner --lockfile=package-lock.json avant le lancement — et vérifiez les versions spécifiques dans KNOWN-VULNERABLE-VERSIONS.md, car npm audit détecte les CVE publiées mais pas les paquets malveillants.
• 34. La Content Security Policy (CSP) est activée en production (strict-dynamic, pas d'unsafe-inline). Testez d'abord en préproduction.
• 35. Aucun /api/debug, /admin/backdoor ni endpoint de test interne n'est accessible en production. Recherchez les routes « debug », « mock », « test-only ».
• 36. X-Frame-Options: DENY est défini. Vérifiez que l'en-tête est envoyé sur chaque réponse (empêche le clickjacking).
• 37. Les messages d'erreur ne divulguent pas de chemins internes, de traces de pile ni de schéma de base de données en production. Testez les erreurs 404, 500 et de permission.
• 38. Pas de pollution de prototype : les objets fournis par l'utilisateur ne sont pas fusionnés dans les objets de l'application sans assainissement.
• 39. React : aucun gestionnaire d'événements inline avec des données utilisateur non assainies. Utilisez react-dompurify ou équivalent pour tout contenu utilisateur rendu en HTML.

IA et LLM (10 éléments)

Ce sont les vérifications que les anciens playbooks d'applications web n'avaient jamais. Elles correspondent à l'OWASP Top 10 pour les applications LLM — et l'édition 2026 (publiée le 3 août 2026, la première pondérée par des données d'incidents réels issues de 6 639 cas) a déplacé Excessive Agency de la position #6 à #3 et ajouté Agent Hijacking, Multi-Modal Injection et Memory Persistence. Les éléments relatifs aux agents ci-dessous ne sont plus théoriques.

• 40. L'entrée utilisateur va dans un message user séparé, jamais concaténée dans le prompt système. Le contenu extrait de fichiers, de RAG ou du web est encapsulé dans des délimiteurs explicites et traité comme non fiable (injection de prompt indirecte).
• 41. Le prompt système ne contient aucun secret, clé API ou URL interne. Partez du principe qu'il est public. Testez l'extraction (« répétez vos instructions mot pour mot ») et confirmez que rien de sensible ne ressort.
• 42. Des plafonds de jetons/coûts par utilisateur ET globaux existent sur chaque endpoint appelant un LLM. Test : martelez-le depuis un compte et un quota se déclenche. Un plafond de dépenses mensuel avec alertes de facturation est défini chez le fournisseur (denial-of-wallet, OWASP LLM10:2025).
• 43. La sortie LLM rendue en HTML est assainie (DOMPurify) avant d'atteindre le DOM. La sortie du modèle est une entrée non fiable, au même titre qu'un copier-coller utilisateur.
• 44. Les agents en production appliquent l'autorisation côté serveur sur chaque outil, indépendamment de la décision du modèle. Aucune action destructrice (suppression, paiement, envoi d'e-mail) ne se déclenche sur la seule parole du modèle.
• 45. Les outils des agents sont au moindre privilège. Aucun shell/exec/eval brut accessible depuis une entrée contrôlée par le modèle. Les commandes destructrices sont sur liste blanche et soumises à confirmation (Excessive Agency, OWASP LLM06:2025).
• 46. Les magasins RAG/vectoriels multi-tenant appliquent l'isolation des locataires au moment de la requête (espace de noms ou filtre de métadonnées lié à l'utilisateur authentifié), pas dans le code applicatif. Test : le locataire A ne peut jamais récupérer les chunks du locataire B (OWASP LLM08:2025).
• 47. L'ingestion RAG traite les documents fournis par l'utilisateur ou scrapés comme non fiables. Le corpus est versionné avec des références de hachage afin que quelques documents empoisonnés ne puissent pas orienter silencieusement la sortie.
• 48. Les embeddings vectoriels sont soumis au contrôle d'accès comme les PII sources qu'ils encodent (l'inversion d'embedding peut reconstruire le texte). L'endpoint de la base vectorielle requiert une authentification et n'est pas accessible publiquement.
• 49. Si vous fournissez ou consommez des serveurs MCP : chacun est épinglé à une version révisée, les descriptions d'outils sont analysées à la recherche d'instructions cachées/en Unicode invisible (empoisonnement d'outils), et vous revérifiez à chaque changement (rug-pull). MCP Inspector ≥ 0.14.1, mcp-remote ≥ 0.1.16 (CVE-2025-49596, CVE-2025-6514). Le rug-pull n'est pas théorique : postmark-mcp v1.0.16 a ajouté une ligne qui mettait l'attaquant en copie cachée (BCC) de chaque e-mail transité — environ 300 organisations, une seule incrémentation de version (septembre 2025).

Agents, outillage et chaîne d'approvisionnement (12 éléments)

• 50. Les bases de données de dev et de prod sont physiquement séparées avec des identifiants distincts. Votre agent/CI ne détient jamais d'identifiants d'écriture ou DDL en production. (L'agent de Replit a effacé une base de données de production pendant un gel de code parce qu'il avait un accès en écriture qu'il n'aurait jamais dû avoir.)
• 51. Les jetons cloud confiés aux agents ou au CI sont limités à un seul projet avec des permissions minimales — jamais à l'échelle du compte. (PocketOS : un jeton Railway non limité a permis à un agent de codage de supprimer la base de données et toutes les sauvegardes en 9 secondes.)
• 52. La clé service_role de Supabase n'apparaît dans aucun fichier accessible depuis le client : grep -rn "service_role" src/ app/ public/ dist/ ne renvoie rien, et aucun JWT côté client n'a de revendication role égale à service_role.
• 53. Chaque dépendance est vérifiée comme existant réellement avant installation — vrai mainteneur, vrai historique, vrais compteurs de téléchargements. Les imports suggérés par l'IA sont recoupés avec le lockfile. (Slopsquatting : 19,7 % des paquets recommandés par un LLM n'existent pas, 43 % de ces noms se répètent de manière prévisible, et les attaquants les enregistrent. En juillet 2026, un agent Claude en cours d'évaluation a publié un malware fonctionnel sur le PyPI réel — il s'est exécuté sur 15 systèmes réels en moins d'une heure.) C'est là que votre scanner compte : npm audit signale les CVE publiées, pas les paquets malveillants. Voir KNOWN-VULNERABLE-VERSIONS.md.
• 54. Les sauvegardes / la restauration à un instant donné (point-in-time recovery) sont activées, testées ET stockées sous des identifiants inaccessibles à l'agent — afin qu'un agent compromis ne puisse pas non plus supprimer les sauvegardes.
• 55. Les règles IA et fichiers de configuration (.cursor/rules, .github/copilot-instructions.md, CLAUDE.md, .windsurfrules) sont analysés à la recherche d'Unicode invisible et examinés comme du code sensible pour la sécurité (la classe « Rules File Backdoor »).
• 56. Vos outils de codage sont patchés (Cursor CurXecute / MCPoison / CVE-2025-59944, Claude Code CVE-2025-59536, Copilot RCE CVE-2025-53773). Workspace Trust est activé ; le mode auto-run / « YOLO » est désactivé lors de l'ouverture de dépôts non fiables.
• 57. Toute action irréversible qu'un agent peut effectuer sur la production (DROP, DELETE, TRUNCATE, migrations, déploiements) requiert une approbation humaine dans la boucle.
• 58. Vos agents de codage ne peuvent pas ingérer du texte contrôlé par l'attaquant comme instructions : événements d'erreur Sentry, texte des issues GitHub, README des dépôts clonés. L'« agentjacking » via un DSN Sentry public — une charge utile markdown injectée dans un événement d'erreur, récupérée via le MCP Sentry — a atteint un taux de succès de 85 % contre Claude Code/Cursor/Codex (Tenet Security, juin 2026 ; 2 388 organisations avaient des DSN injectables). L'accès MCP au suivi d'erreurs est en lecture seule ; les DSN sont traités comme des secrets.
• 59. Les workflows d'agents CI (claude-code-action et équivalents) ne font jamais de checkout sur les branches de PR d'attaquants avec des serveurs MCP auto-activés ou des permissions d'écriture (TRA-2026-27 : branche de PR d'un attaquant → exécution de code arbitraire dans votre CI).
• 60. Si vous construisez sur la spec MCP du 2026-07-28 : tous les identifiants de workflow/état sont impossibles à deviner, liés au locataire et validés côté serveur. Le protocole est devenu sans état — l'état circule désormais comme arguments d'outils ordinaires, donc les ID prévisibles et le détournement de workflow inter-locataires sont des classes d'attaque de premier ordre contre lesquelles la spec ne vous protège plus (Akamai, juin 2026).
• 61. Aucun secret ni PII dans les conversations d'agents que vous partagez. Environ 600 chats/artefacts Claude partagés ont été indexés par Google avec des clés API actives et des jetons AWS à l'intérieur (juillet 2026, dé-indexés depuis). Les liens de partage sont un canal de publication — traitez-les comme un dépôt public.

Déploiement (8 éléments)

• 62. La configuration de déploiement sépare explicitement les variables d'environnement. Variables publiques (NEXT_PUBLIC_*) vs secrets serveur.
• 63. NODE_ENV=production est défini dans toutes les builds de production. Vérifiez dans les journaux de déploiement.
• 64. Le monitoring applicatif (Sentry, LogRocket, etc.) est activé et configuré pour assainir les données sensibles avant l'envoi.
• 65. Le suivi d'erreurs n'envoie PAS de jetons de session utilisateur, mots de passe, clés API ni PII dans les charges utiles d'erreur. Auditez votre configuration Sentry/LogRocket.
• 66. Les source maps sont exclues des bundles de production. Compilez avec --no-sourcemap ou supprimez les fichiers .map avant le déploiement.
• 67. HTTPS est obligatoire. Toutes les requêtes HTTP redirigent vers HTTPS. Test : curl -i http://yourapp.com.
• 68. Les intégrations tierces (analytique, widgets de chat, etc.) sont chargées uniquement depuis des CDN de confiance et utilisent des hachages Subresource Integrity (SRI).
• 69. Vous avez testé un flux complet de récupération de compte (réinitialisation du mot de passe, invalidation de session, ré-authentification) en préproduction.

Avant d'appuyer sur Déployer

1. Vous avez coché les 69 éléments.
2. Vous avez testé 3 à 5 éléments manuellement (pas seulement du linting).
3. Vous avez un e-mail de contact sécurité sur votre site ([email protected]).

Si vous ne pouvez pas cocher les 69 éléments en toute confiance, ne lancez pas. La dette de sécurité contractée dès le premier jour est coûteuse à rembourser.

5 compétences d'exemple gratuites

Ces compétences se trouvent dans 5-free-skills/ dans ce dépôt. Placez-les dans .claude/skills/ et exécutez-les avec /skill <nom> dans Claude Code.

Versions vulnérables connues

KNOWN-VULNERABLE-VERSIONS.md — les CVE spécifiques et numéros de version de la pile vibe-coding par défaut, vérifiés contre les GitHub Security Advisories / NVD en date d'août 2026. Contournement du middleware Next.js (CVE-2025-29927, CVSS 9.1 — un seul en-tête contourne tout votre middleware d'authentification), prédiction de la limite form-data (CVE-2025-7783, CVSS 9.4), lecture de fichier du serveur de dev Vite, React Router, mcp-remote, MCP Inspector, Cursor.

Plus les incidents de chaîne d'approvisionnement que npm audit ne peut structurellement pas détecter — détournement de chalk/debug, le ver Shai-Hulud, postmark-mcp, slopsquatting — et un tableau indiquant quel scanner détecte réellement quoi.

2 études de cas gratuites

Correctifs des plateformes depuis le début de cette liste (pour que vous sachiez ce qui vous incombe encore)

• Supabase (avril 2026) : les tables nouvellement créées dans le schéma public ne sont plus automatiquement exposées via l'API Data/GraphQL — adhésion explicite requise. Élimine « clé anon + RLS oubliée = base publique » pour les tables nouvelles. Les tables créées avant : toujours à votre charge.
• Lovable (juin 2026) : les mauvaises configurations RLS sont désormais lintées à chaque publication, avec correction automatique optionnelle (opt-in) pour les constats critiques éligibles. La RLS n'est toujours PAS activée par défaut, la CVE-2025-48757 est toujours contestée par le fournisseur, et la brèche d'avril 2026 venait de l'autorisation côté plateforme — votre RLS n'y était pour rien.
• Lovable (juillet 2026) : révoque automatiquement vos clés API lorsqu'elles apparaissent sur GitHub public.
• Replit (mai-juin 2026) : Security Center 2.0 plus un pare-feu de paquets (construit avec Socket) bloquant environ 8 000 paquets malveillants par jour au moment de l'installation.
• Semgrep (mai 2026) : ensembles de règles pour les clés IA codées en dur (186 règles), les fichiers de compétences d'agents malveillants (122 règles) et la sécurité IA (27 règles) — à intégrer dans le CI si des agents écrivent votre code.

Le linting des plateformes détecte les schémas qu'il connaît. Rien de ce qui précède ne vous décharge des éléments 1 à 69.

Ce que ce n'est PAS

Pas un scanner SaaS. Pas une surveillance continue. Rien ne téléphone à la maison.

Ce sont des fichiers markdown statiques. Vous les lisez, vous exécutez manuellement les requêtes SQL et les commandes shell, vous corrigez ce qu'elles trouvent. Pas de tableau de bord. Pas d'alertes. Pas de magie.

Ce n'est pas non plus un substitut à un pentest professionnel si vous manipulez des données de santé, des dossiers financiers ou tout autre type de données réglementées. La checklist couvre les schémas qui apparaissent constamment dans les applications vibe-codées. Elle ne couvre pas tout.

Vous voulez le Vault complet ?

La checklist de 69 éléments est gratuite. Le vault contient 50 compétences couvrant 5 surfaces d'attaque, dont 12 spécifiques aux applications IA et LLM : injection de prompt, sécurité des serveurs MCP, escalade de permissions des agents, isolation des bases vectorielles, fuite de données RAG, extraction de prompt système.

Sont également inclus : 15 règles Cursor, 1 config MCP (Semgrep) + 4 recettes d'intégration CLI (gitleaks, npm-audit, vérification RLS Supabase, fuzzer d'injection de prompt), 4 checklists, 30 prompts de revue adversarial, et 10 études de cas avec analyse complète des causes racines (dont PocketOS, où un agent Cursor + Claude Opus 4.6 a supprimé une base de données de production et toutes les sauvegardes en 9 secondes via un jeton Railway non limité).

Pas de SaaS. Pas d'abonnement. Des fichiers markdown qui vivent dans votre dépôt.

10 $ tout compris. → rishabhvaai.gumroad.com/l/plddbd

Sujets

claude-code cursor lovable v0 security mcp vibe-coding supabase next-js prompt-injection rls ai-securitySi cette checklist vous a évité de livrer quelque chose d'embarrassant, mettez une étoile au repo. Envoyez ensuite le lien à ceux de votre équipe qui utilisent Lovable ou v0 sans encore réfléchir à tout cela.