Vibe Coding Security

Avant de tweeter votre lancement, exécutez ces 69 vérifications. Elles correspondent aux schémas exacts à l'origine de la CVE Lovable RLS (CVE-2025-48757, 170+ applications, 2025), de la fuite Moltbook (1,5 million de jetons API, février 2026) et de la brèche de la plateforme Lovable d'avril 2026 (code source + clés de service des projets d'autres utilisateurs, exposés pendant ~2,5 mois).

Envie du kit complet ? 50 compétences d'audit, 15 .cursorrules, 1 config MCP + 4 recettes CLI, 30 prompts de revue adversarial, 10 études de cas. Installation en 5 minutes. 10 $ tout compris.

→ rishabhvaai.gumroad.com/l/plddbd

Dans un audit publié en octobre 2025, Escape.tech a analysé 5 600 applications réelles générées par IA sur 14 600 actifs (méthodologie). Ils ont signalé 2 038 vulnérabilités critiques, plus de 400 secrets divulgués et 175 cas de PII exposées dans 1 400 de ces applications (résultats). Les secrets provenaient directement des bundles frontend : des clés Stripe, OpenAI et Supabase présentes dans le JavaScript côté client. La situation ne s'est pas améliorée depuis : le rapport 2026 de GitGuardian a dénombré 28,6 millions de nouveaux secrets sur GitHub public en 2025 (+34 % en glissement annuel), les secrets de services IA en hausse de 81 %, et des commits co-écrits par des agents de codage qui fuient des secrets à environ 2 fois le taux humain de référence. Voici une checklist de 69 éléments spécifiques et testables. Chacun correspond à un schéma d'incident réel. Si vous pouvez cocher les 69, lancez. Si vous ne pouvez pas, corrigez ce qui vous bloque.

Pas un SaaS. Pas un scanner. Une simple liste que vous parcourez avant de pousser en prod.

La checklist de sécurité pré-lancement en 69 points

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)

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.

vibe-coding-security

Populaires

À propos