Comment sécuriser le code généré par l'IA — Liste de contrôle de sécurité Vibe Coding

Si tu as codé une app en vibe avec Claude ou Cursor et tu t'apprêtes à la remettre à un client payant, arrête-toi. Le code généré par l'IA arrive avec des trous de sécurité prévisibles — des clés API exposées, une validation d'entrée manquante, des permissions de base de données par défaut qui laissent n'importe quel utilisateur voir les données de tout le monde. Ce ne sont pas des cas limites. Ça arrive dans presque chaque première version d'une base de code générée par l'IA.

Ce guide est la checklist de sécurité avant le lancement. Suis-le étape par étape avant que n'importe quel vrai utilisateur touche à ton app. C'est écrit pour la stack vibe coding la plus courante (Next.js + Supabase + Vercel), mais les principes s'appliquent quel que soit tes outils.

Pourquoi le code généré par l'IA a des problèmes de sécurité

Les modèles d'IA optimisent pour « est-ce que ça marche ? » et non pas « est-ce que c'est sécurisé ? » Quand tu dis à Claude « construis-moi un gestionnaire de tâches avec des comptes utilisateurs », il va générer du code qui crée les utilisateurs, stocke les tâches et les affiche. Ce qu'il ne fera probablement pas automatiquement : s'assurer que l'Utilisateur A ne peut pas voir les tâches de l'Utilisateur B, valider que les champs d'entrée ne peuvent pas accepter des scripts malveillants, cacher tes clés API des outils de développement du navigateur, ou ajouter une limitation de débit pour empêcher quelqu'un de surcharger tes endpoints.

Ce ne sont pas des échecs de l'IA — ce sont des lacunes dans le prompt. L'IA construit ce que tu as demandé. Tu n'as probablement pas demandé la sécurité parce que tu te concentrais sur les fonctionnalités. Maintenant, c'est le moment de revenir en arrière et de l'ajouter.

Étape 1 : Auditer tes variables d'environnement

C'est l'erreur la plus courante et la plus dangereuse dans les apps codées en vibe. Vérifie chaque fichier de ton projet pour les clés API codées en dur, les URLs de bases de données ou les secrets.

Quoi chercher : Recherche dans ta base de code les chaînes qui commencent par sk-, eyJ, sbp_, supabase, postgres://, ou toute chaîne longue ressemblant à du hasard. Vérifie spécifiquement ces fichiers : tout fichier de ton répertoire /app ou /pages, tout fichier de composant, ton next.config.js, et tous les fichiers utilitaires.

La correction : Déplace chaque secret dans les variables d'environnement. Dans Next.js, seules les variables commençant par NEXT_PUBLIC_ sont exposées au navigateur. L'URL de ta base de données, la clé de rôle de service et tes secrets API ne devraient jamais avoir ce préfixe.

# .env.local (NE COMMIT JAMAIS CE FICHIER)
SUPABASE_SERVICE_ROLE_KEY=ta-clé-secrète
DATABASE_URL=postgres://...

# Celles-ci peuvent être exposées au navigateur :
NEXT_PUBLIC_SUPABASE_URL=https://ton-projet.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=ta-clé-anon

Vérifier : Vérifie que ton fichier .gitignore inclut .env.local. Si tu as déjà commité des secrets dans Git, ils sont dans ton historique même après suppression — régénère immédiatement chaque clé exposée.

Étape 2 : Activer la sécurité au niveau des lignes dans Supabase

C'est l'étape la plus critique si tu utilises Supabase. Par défaut, les tables Supabase n'ont aucune restriction d'accès — n'importe qui avec ta clé anon peut lire et écrire chaque ligne dans chaque table. Cela signifie que l'Utilisateur A peut voir les données de l'Utilisateur B avec un simple appel API.

La correction : Active la sécurité au niveau des lignes (RLS) sur chaque table, puis crée des politiques qui restreignent l'accès.

Va dans ton tableau de bord Supabase → Éditeur de tableau → sélectionne chaque tableau → clique sur « RLS Désactivée » pour l'activer. Puis ajoute des politiques :

Pour une app typique où les utilisateurs ne devraient voir que leurs propres données, crée une politique SELECT : auth.uid() = user_id. Crée des politiques similaires pour INSERT, UPDATE et DELETE.

Tester : Connecte-toi en tant qu'Utilisateur A, essaie d'accéder aux données de l'Utilisateur B via l'API. Si tu peux les voir, tes politiques sont incorrectes. Supabase a un éditeur SQL où tu peux tester les politiques directement.

Erreur courante de l'IA : Claude génère souvent des requêtes Supabase en utilisant la clé service_role (qui contourne RLS) au lieu de la clé anon avec les politiques RLS appropriées. Vérifie que ton code côté client utilise uniquement la clé anon. La clé de rôle de service ne devrait exister que dans le code côté serveur (routes API, actions serveur) et ne jamais être exposée au navigateur.

Étape 3 : Ajouter l'authentification correctement

Le code d'authentification généré par l'IA fonctionne souvent mais prend des raccourcis. Vérifie ces problèmes spécifiques :

Gestion des sessions : Assure-toi que les sessions expirent. Vérifie que ta configuration d'authentification inclut un délai d'expiration de session raisonnable (les valeurs par défaut de Supabase sont généralement correctes, mais vérifie). Assure-toi que la déconnexion invalide réellement la session, pas juste efface le cookie local.

Exigences de mot de passe : Si tu as une authentification par email/mot de passe, applique une longueur minimale de mot de passe (8+ caractères). Supabase gère cela dans les paramètres de ton projet → Authentification → Exigences de mot de passe.

Routes protégées : Chaque page qui affiche des données spécifiques à l'utilisateur a besoin d'un middleware d'authentification. Dans Next.js App Router, crée un middleware qui vérifie une session valide et redirige les utilisateurs non authentifiés vers la page de connexion. Ne te fie pas uniquement aux vérifications côté client — un utilisateur peut les contourner en frappant directement ton API.

Vérification d'email : Active la confirmation d'email dans les paramètres de Supabase Auth. Cela empêche les gens de créer des comptes avec des adresses email fictives et ajoute une couche basique de validité du compte.

Étape 4 : Valider toutes les entrées

Les formulaires générés par l'IA ont généralement une validation basique (champs obligatoires, format email) mais protègent rarement contre les entrées malveillantes.

Ce qu'il faut ajouter :

Validation côté serveur sur chaque endpoint API. Ne fais jamais confiance uniquement à la validation côté client — elle peut être contournée en envoyant des requêtes directement à ton API. Utilise une bibliothèque de validation comme Zod (pour TypeScript) pour définir des schémas pour chaque information que ton app accepte.

Nettoie l'HTML dans tout contenu généré par l'utilisateur qui s'affiche. Si ton app a des commentaires, des descriptions ou tout champ de texte qui s'affiche dans le navigateur, utilise une bibliothèque comme DOMPurify pour éliminer les scripts dangereux. Sans cela, quelqu'un peut injecter du JavaScript qui vole les sessions d'autres utilisateurs (cross-site scripting / XSS).

Limite la taille et les types de fichier si ton app accepte les téléchargements de fichiers. Les gestionnaires de téléchargement générés par l'IA n'ont souvent aucune limite, ce qui signifie que quelqu'un pourrait télécharger un fichier de 2GB ou un exécutable. Ajoute des limites de taille (5MB est raisonnable pour la plupart des apps) et restreins les types de fichier à ce dont tu as vraiment besoin (images, PDFs, etc.).

Étape 5 : Sécuriser tes routes API

Vérifie chaque route API ou action serveur dans ton app pour ces problèmes :

Authentification sur chaque endpoint. Chaque route API qui retourne ou modifie les données de l'utilisateur devrait d'abord vérifier la session de l'utilisateur. L'IA génère souvent des routes API qui acceptent les requêtes de n'importe qui.

Autorisation au-delà de l'authentification. Même après avoir confirmé qu'un utilisateur est connecté, vérifie qu'il est autorisé à accéder à la ressource spécifique qu'il demande. « L'Utilisateur A est connecté » ne signifie pas « l'Utilisateur A peut modifier le profil de l'Utilisateur B ». Vérifie la propriété sur chaque accès aux données.

Limitation de débit. Sans limitation de débit, quelqu'un peut envoyer des milliers de requêtes par seconde à ton API, soit pour gratter les données, soit pour surcharger ton serveur. Ajoute une limitation de débit basique en utilisant une bibliothèque comme rate-limiter-flexible ou utilise la limitation de débit intégrée de Vercel sur les Edge Functions.

Méthodes HTTP. Assure-toi que tes routes API ne répondent qu'aux méthodes HTTP qu'elles devraient. Une route qui gère les requêtes POST ne devrait pas aussi répondre aux requêtes DELETE à moins que tu l'aies explicitement conçu.

Étape 6 : Vérifier ta configuration de déploiement

Ta plateforme de déploiement a des paramètres de sécurité que l'IA ne configure pas pour toi.

Paramètres Vercel à vérifier : Active la « Protection de déploiement » (nécessite l'authentification pour afficher les déploiements d'aperçu — empêche les clients de partager accidentellement les URLs d'aperçu qui exposent le travail en cours). Configure les limites de dépenses pour éviter les frais inattendus si ton app reçoit des pics de trafic. Configure tes domaines autorisés dans les en-têtes CORS.

Domaine personnalisé et SSL : Si tu livres cela à un client, configure son domaine personnalisé avec HTTPS. Vercel et Netlify gèrent SSL automatiquement. Ne livre jamais une app client sur un sous-domaine .vercel.app — cela semble peu professionnel et le client ne peut pas le transférer facilement.

En-têtes : Ajoute les en-têtes de sécurité à ton next.config.js ou vercel.json : X-Content-Type-Options: nosniff, X-Frame-Options: DENY (empêche ton site d'être intégré dans les iframes pour le clickjacking), Strict-Transport-Security (force HTTPS). Ce sont des ajouts ponctuels qui préviennent toute une classe d'attaques.

Étape 7 : Effectuer une analyse de sécurité finale

Avant de remettre quelque chose à un client, exécute ces vérifications gratuites :

npm audit : Exécute npm audit dans le répertoire de ton projet. Cela signale les vulnérabilités connues dans tes dépendances. Corrige les problèmes critiques et de haute gravité. Exécute npm audit fix pour les corrections automatiques où disponibles.

Lighthouse : Ouvre ton site déployé dans Chrome, ouvre DevTools, exécute un audit Lighthouse. Vérifie le score « Meilleures pratiques » — il détecte les problèmes de sécurité courants comme le HTTPS manquant, les bibliothèques vulnérables et les en-têtes non sécurisés.

Tests manuels : Connecte-toi en tant qu'Utilisateur A, essaie d'accéder aux données d'un autre utilisateur en modifiant les URLs ou les appels API. Essaie de soumettre des formulaires vides, des entrées surdimensionnées et des caractères spéciaux (comme des charges XSS encodées). Si l'une de ces actions fonctionne, tu as des problèmes à corriger.

La checklist avant le lancement

Imprime ceci et vérifie chaque élément avant de lancer :

• Tous les secrets dans les variables d'environnement (pas de clés codées en dur)
• .env.local dans .gitignore (et pas de secrets dans l'historique Git)
• Supabase RLS activée sur chaque tableau
• Politiques RLS testées (l'Utilisateur A ne peut pas voir les données de l'Utilisateur B)
• Le code côté client utilise uniquement la clé anon (clé de rôle de service serveur uniquement)
• Authentification sur chaque route API
• Vérifications d'autorisation (vérification de la propriété) sur l'accès aux données
• Validation d'entrée sur chaque formulaire (côté serveur, pas seulement côté client)
• Limites de téléchargement de fichiers (taille et type) si applicable
• Limitation de débit sur les endpoints API
• En-têtes de sécurité configurés
• npm audit exécuté et problèmes critiques corrigés
• Domaine personnalisé avec SSL configuré
• Déploiements d'aperçu protégés
• Test d'accès aux données entre utilisateurs réussi

Le résultat

Sécuriser une app codée en vibe, ce n'est pas devenir un expert en sécurité. C'est suivre une checklist qui capture les lacunes prévisibles que l'IA laisse derrière elle. Les étapes ci-dessus prennent 2–4 heures et préviennent les vulnérabilités les plus courantes. Pour une app orientée client, ce n'est pas optionnel — c'est la différence entre un travail professionnel et une responsabilité.

Si tu construis ta première app codée en vibe, commence par notre guide complet du vibe coding. Si tu veux améliorer les prompts que tu utilises avec Claude ou Cursor, essaie notre optimiseur de prompt gratuit. Et pour une ventilation des meilleurs outils de codage, vois Claude Code vs Codex.

Divulgation : Certains liens dans cet article sont des liens d'affiliation. Nous ne recommandons que les outils que nous avons personnellement testés et utilisons régulièrement. Voir notre politique complète de divulgation.