antoniovjrf/ultra-thermo-nuclear-vibecoding-security-review

Ultra Thermo Nuclear VibeCoding Security Review — Compétence d'Agent

Principe Fondamental

Ne jamais faire confiance au client. Chaque prix, ID utilisateur, rôle, statut d'abonnement, indicateur de fonctionnalité et compteur de limitation de débit doit être validé ou imposé côté serveur. Si une valeur existe uniquement dans le navigateur, le bundle mobile ou le corps de la requête, un attaquant la contrôle.

Principes supplémentaires — voir core/principles.md :

• Défense en profondeur : ne jamais se fier à un seul contrôle de sécurité
• Échec sécurisé : en cas de problème, refuser l'accès (fermeture sécurisée)
• Moindre privilège : accorder les permissions minimales nécessaires
• Validation des entrées : ne jamais faire confiance aux entrées utilisateur — tout valider côté serveur
• Encodage de sortie : encoder les données pour le contexte dans lequel elles sont rendues

---

Modes de Fonctionnement

Mode 1 : AUDIT (analyse post-hoc)

Déclenché par : "exécuter un audit de sécurité", "vérifier les vulnérabilités", "audit de sécurité vibe", "est-ce que c'est sûr ?", ou toute demande explicite de révision de code existant.

Processus :

1. Détecter la pile technique (voir Étape 1 ci-dessous)
2. Exécuter la checklist en 50 points — voir core/audit-process.md
3. Calculer le score et compiler le rapport — voir core/output-format.md
4. Charger les références de vulnérabilité et les modules de la pile si nécessaire

Mode 2 : PRÉVENTIF (pendant la génération de code)

Déclenché par : l'écriture ou la révision de code qui touche à l'authentification, aux paiements, à l'accès à la base de données, aux clés API, aux secrets, aux données utilisateur ou aux téléchargements de fichiers — même si l'utilisateur ne mentionne pas la sécurité.

Processus :

1. Identifier le domaine de sécurité applicable au code en cours d'écriture
2. Consulter le(s) fichier(s) de référence approprié(s) AVANT de générer le code
3. Appliquer les modèles sécurisés dès le départ
4. Ajouter des commentaires en ligne expliquant les décisions de sécurité lorsque celles-ci ne sont pas évidentes
5. Signaler tout compromis de sécurité à l'utilisateur

---

Étape 1 : Détecter la Pile Technique

Identifier les technologies du projet en examinant ces fichiers :

Détecter	Chercher
Framework	next.config.*, nuxt.config.*, astro.config.*, vite.config.*, angular.json, svelte.config.*
Gestionnaire de paquets	package.json, requirements.txt, go.mod, Gemfile, Cargo.toml, pubspec.yaml
Base de données	prisma/, drizzle.config.*, supabase/, firebase.json, convex/
Authentification	Imports : @clerk, next-auth, @supabase/auth, @auth0, lucia, passport, firebase/auth
Stockage	Imports : @aws-sdk/client-s3, @supabase/storage, @google-cloud/storage
API IA	Imports : openai, @anthropic-ai/sdk, @google/generative-ai, langchain, @ai-sdk
Paiement	Imports : stripe, @paddle/paddle-node, @lemonsqueezy
Email	Imports : resend, @sendgrid/mail, nodemailer
GraphQL	schema.graphql, imports : @apollo/server, graphql-yoga, type-graphql
Mobile	app.json (Expo), react-native.config.js, capacitor.config.*
Déploiement	vercel.json, netlify.toml, fly.toml, Dockerfile, docker-compose.*, .github/workflows/
Runtime Edge	wrangler.toml, directives de runtime edge dans le code source

Ignorer les vérifications qui ne s'appliquent pas à la pile détectée.

---

Étape 2 : Exécuter l'Audit

Charger les fichiers de checklist appropriés et exécuter :

Progression de l'audit :
- [ ] Étape 1 : Détecter la pile technique
- [ ] Étape 2a : Exécuter les vérifications critiques (1-15) — voir checklists/critical-15.md
- [ ] Étape 2b : Exécuter les vérifications standard (16-40) — voir checklists/standard-25.md
- [ ] Étape 2c : Exécuter les vérifications de production (41-50) — voir checklists/production-10.md
- [ ] Étape 3 : Calculer le score et compiler le rapport — voir core/output-format.md

Exécuter d'abord les vérifications critiques — lire checklists/critical-15.md et effectuer toutes les vérifications avant de continuer.

Pour chaque vérification, consulter les fichiers de référence appropriés :

• Détails des vulnérabilités → vulnerabilities/*.md
• Modèles spécifiques à la pile → stack/*.md
• Préparation à la production → production/*.md

Échelle de Sévérité

Score	Niveau	Action Requise
10/10	Critique	Corriger avant déploiement
8-9/10	Élevée	Corriger sous 24 heures
6-7/10	Moyenne	Corriger sous 1 semaine
4-5/10	Faible	Corriger quand c'est pratique
1-3/10	Informatif	Envisager une correction

Score du projet = 100 moins la somme des scores de sévérité de tous les problèmes trouvés (minimum 0).

Score	Évaluation
90-100	✅ Excellent
70-89	⚠️ Bon — problèmes mineurs
50-69	🟡 Moyen — nécessite attention
30-49	🟠 Médiocre — risque important
0-29	🔴 Critique — ne pas déployer

---

Étape 3 : Générer le Rapport

Utiliser le format défini dans core/output-format.md. Exigences clés :

• Référencer les fichiers et numéros de ligne exacts
• Montrer le modèle qui correspond à chaque constat
• Fournir des différences de code avant/après pour chaque problème
• Inclure une section Quick Wins (corrigeable en moins de 10 minutes)
• Terminer par un résumé priorisé

---

Index des Références

Core

• core/principles.md — Principes de sécurité et stratégies de défense en profondeur
• core/audit-process.md — Routage et ordre d'exécution de la checklist en 50 points
• core/output-format.md — Modèle de rapport avec notation

Base de Connaissances des Vulnérabilités

• vulnerabilities/injection.md — Injection SQL, XSS, injection de commandes, injection LDAP
• vulnerabilities/access-control.md — IDOR, escalade de privilèges, mass assignment
• vulnerabilities/authentication.md — JWT, OAuth 2.0, PKCE, gestion de sessions, sécurité des mots de passe
• vulnerabilities/csrf-ssrf.md — CSRF, SSRF, redirection ouverte (avec tableaux de techniques de contournement)
• vulnerabilities/file-upload.md — Octets magiques, fichiers polyglottes, ZIP slip, SVG XSS
• vulnerabilities/cryptography.md — Chiffrement, hachage, gestion des clés, réutilisation de nonce
• vulnerabilities/race-conditions.md — TOCTOU, double dépense, modèles de mutex

Modules Spécifiques aux Piles

• stack/supabase.md — Politiques RLS, auth, stockage, edge functions
• stack/firebase.md — Règles de sécurité, Firestore, auth
• stack/nextjs.md — Server Actions, Middleware, Route Handlers, App Router
• stack/stripe-payments.md — Webhooks, validation des prix, flux d'abonnement
• stack/react-native.md — Stockage sécurisé, proxy API, liens profonds
• stack/ai-llm.md — Protection des clés API, injection d'invites, plafonds d'utilisation, assainissement des sorties
• stack/graphql.md — Introspection, limitation de profondeur, regroupement, requêtes persistées
• stack/docker-cicd.md — Sécurité des conteneurs, durcissement des pipelines

Préparation à la Production

• production/security-headers.md — CSP, HSTS, X-Frame-Options, Permissions-Policy
• production/deployment.md — Source maps, séparation des environnements, points de terminaison de débogage
• production/compliance.md — RGPD, CCPA, suppression de compte, conservation des données
• production/observability.md — Sécurité de la journalisation, assainissement des données personnelles, surveillance
• production/dependency-audit.md — Paquets fantômes, typosquatting, attaques sur la chaîne d'approvisionnement

Checklists Exécutables

• checklists/critical-15.md — 15 vérifications critiques (corriger avant déploiement)
• checklists/standard-25.md — 25 vérifications standard (corriger sous 1 semaine)
• checklists/production-10.md — 10 vérifications de préparation à la production (avant la mise en ligne)

---

Lors de la Génération de Code

Ces règles s'appliquent de manière proactive. Avant d'écrire du code qui touche à l'authentification, aux paiements, à l'accès à la base de données, aux clés API ou aux données utilisateur, consulter le fichier de référence approprié pour éviter d'introduire des vulnérabilités dès le départ. Mieux vaut prévenir que guérir.

En cas de doute, choisir l'option la plus restrictive/sécurisée et documenter la considération de sécurité dans des commentaires.