Comment sécuriser une application codée à la volée avant de la confier aux clients

Si vous avez codé une app avec Claude ou Cursor et vous vous apprêtez à la remettre à un client payant, arrêtez-vous. Le code généré par l'IA contient des failles 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 permettent à n'importe quel utilisateur de voir les données de tous les autres. Ce ne sont pas des cas limites. Cela arrive dans presque tous les premiers brouillons de codebase générés par l'IA.

Ce guide est la checklist de sécurité pré-lancement. Suivez-le étape par étape avant que tout vrai utilisateur ne touche à votre app. Il est écrit pour la pile de code-vibe la plus courante (Next.js + Supabase + Vercel), mais les principes s'appliquent quel que soit vos outils.

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

Les modèles d'IA optimisent pour « ça fonctionne-t-il ? » et non « est-ce sécurisé ? » Quand vous dites à Claude « construis-moi un gestionnaire de tâches avec des comptes utilisateur », il générera du code qui crée des 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 de scripts malveillants, cacher vos clés API des outils de développement du navigateur, ou ajouter une limitation de débit pour empêcher quelqu'un de bombarder vos points de terminaison.

Ce ne sont pas des défaillances de l'IA — ce sont des lacunes dans le prompt. L'IA construit ce que vous lui avez demandé. Vous n'avez probablement pas demandé de sécurité parce que vous vous concentriez sur les fonctionnalités. Maintenant, il est temps de revenir en arrière et de l'ajouter.

Étape 1 : Auditez vos variables d'environnement

C'est l'erreur la plus courante et la plus dangereuse dans les apps vibe-codées. Vérifiez chaque fichier de votre projet pour les clés API en dur, les URL de base de données ou les secrets.

Quoi chercher : Recherchez dans votre codebase les chaînes qui commencent par sk-, eyJ, sbp_, supabase, postgres://, ou toute chaîne aléatoire longue. Vérifiez ces fichiers spécifiquement : n'importe quel fichier dans votre répertoire /app ou /pages, n'importe quel fichier composant, votre next.config.js, et n'importe quel fichier utilitaire.

La correction : Déplacez chaque secret dans des variables d'environnement. Dans Next.js, seules les variables préfixées avec NEXT_PUBLIC_ sont exposées au navigateur. L'URL de votre base de données, la clé de rôle de service et les secrets API ne devraient jamais avoir ce préfixe.

# .env.local (NE JAMAIS commiter ce fichier)
SUPABASE_SERVICE_ROLE_KEY=your-secret-key
DATABASE_URL=postgres://...

# Ceux-ci sont okay d'exposer au navigateur :
NEXT_PUBLIC_SUPABASE_URL=https://your-project.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=your-anon-key

Vérifiez : Assurez-vous que votre fichier .gitignore inclut .env.local. Si vous avez déjà commité des secrets dans Git, ils sont dans votre historique même après suppression — regénérez immédiatement chaque clé exposée.

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

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

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

Allez à votre tableau de bord Supabase → Table Editor → sélectionnez chaque table → cliquez sur « RLS Désactivé » pour l'activer. Puis ajoutez des politiques :

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

Testez-la : Connectez-vous en tant qu'utilisateur A, essayez d'accéder aux données de l'utilisateur B via l'API. Si vous pouvez les voir, vos politiques sont incorrectes. Supabase a un éditeur SQL où vous pouvez 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 des politiques RLS appropriées. Vérifiez que votre code côté client n'utilise que la clé anon. La clé service role ne devrait exister que dans le code côté serveur (routes API, server actions) et ne jamais être exposée au navigateur.

Étape 3 : Ajoutez l'authentification correctement

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

Gestion des sessions : Assurez-vous que les sessions expirent. Vérifiez que votre 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érifiez). Assurez-vous que la déconnexion invalide vraiment la session, et non seulement qu'elle efface le cookie local.

Exigences de mot de passe : Si vous avez une authentification par email/mot de passe, appliquez une longueur minimale de mot de passe (8+ caractères). Supabase gère cela dans vos paramètres de projet → Authentication → Password Requirements.

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éez un middleware qui vérifie une session valide et redirige les utilisateurs non authentifiés vers la page de connexion. Ne vous fiez pas uniquement aux vérifications côté client — un utilisateur peut les contourner en frappant directement votre API.

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

Étape 4 : Validez toutes les entrées

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

Quoi ajouter :

Validation côté serveur sur chaque point de terminaison API. Ne faites jamais confiance à la validation côté client seule — elle peut être contournée en envoyant directement des requêtes à votre API. Utilisez une bibliothèque de validation comme Zod (pour TypeScript) pour définir des schémas pour chaque donnée que votre app accepte.

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

Limitez la taille et les types de fichiers si votre 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 2 Go ou un exécutable. Ajoutez des limites de taille (5 Mo est raisonnable pour la plupart des apps) et limitez les types de fichiers à ce que vous avez vraiment besoin (images, PDF, etc.).

Étape 5 : Sécurisez vos routes API

Vérifiez chaque route API ou server action dans votre app pour ces problèmes :

Authentification sur chaque point de terminaison. Chaque route API qui retourne ou modifie des données utilisateur doit 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érifiez 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érifiez la propriété à 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 à votre API, soit pour extraire des données, soit pour surcharger votre serveur. Ajoutez une limitation de débit basique en utilisant une bibliothèque comme rate-limiter-flexible ou utilisez la limitation de débit intégrée de Vercel sur les Edge Functions.

Méthodes HTTP. Assurez-vous que vos routes API répondent uniquement 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 vous l'ayez explicitement conçu.

Étape 6 : Vérifiez votre configuration de déploiement

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

Paramètres Vercel à vérifier : Activez « Deployment Protection » (nécessite une authentification pour voir les déploiements preview — empêche les clients de partager accidentellement des URL preview qui exposent le travail en cours). Configurez les limites de dépenses pour empêcher les frais inattendus si votre app reçoit des pics de trafic. Configurez vos domaines autorisés dans les en-têtes CORS.

Domaine personnalisé et SSL : Si vous livrez ceci à un client, configurez son domaine personnalisé avec HTTPS. Vercel et Netlify gèrent le SSL automatiquement. Ne livrez jamais une app client sur un sous-domaine .vercel.app — c'est peu professionnel et le client ne peut pas le transférer facilement.

En-têtes : Ajoutez des en-têtes de sécurité à votre next.config.js ou vercel.json : X-Content-Type-Options: nosniff, X-Frame-Options: DENY (empêche votre site d'être intégré dans des iframes pour le clickjacking), Strict-Transport-Security (force HTTPS). Ce sont des ajouts uniques qui préviennent des classes entières d'attaques.

Étape 7 : Exécutez une vérification de sécurité finale

Avant de remettre quoi que ce soit à un client, exécutez ces vérifications gratuites :

npm audit : Exécutez npm audit dans votre répertoire de projet. Cela signale les vulnérabilités connues dans vos dépendances. Corrigez les problèmes critiques et de haute gravité. Exécutez npm audit fix pour les corrections automatiques si disponibles.

Lighthouse : Ouvrez votre site déployé dans Chrome, ouvrez DevTools, exécutez un audit Lighthouse. Vérifiez le score « Best Practices » — cela attrape 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.

Test manuel : Connectez-vous en tant qu'utilisateur, essayez d'accéder aux données d'un autre utilisateur en modifiant les URL ou les appels API. Essayez de soumettre des formulaires vides, des entrées oversized et des caractères spéciaux (comme des payloads XSS encodés). Si l'un de ceux-ci fonctionne, vous avez des problèmes à corriger.

La checklist pré-lancement

Imprimez ceci et vérifiez chaque élément avant d'aller en ligne :

• Tous les secrets dans les variables d'environnement (pas de clés en dur)
• .env.local dans .gitignore (et pas de secrets dans l'historique Git)
• Supabase RLS activé sur chaque table
• Politiques RLS testées (l'utilisateur A ne peut pas voir les données de l'utilisateur B)
• Code côté client utilise uniquement la clé anon (clé service role côté serveur seulement)
• Authentification sur chaque route API
• Vérifications d'autorisation (vérification de 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 points de terminaison 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 preview protégés
• Test d'accès aux données entre utilisateurs réussi

Le résumé

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

Si vous construisez votre première app vibe-codée, commencez par notre guide complet du vibe coding. Si vous voulez améliorer les prompts que vous utilisez avec Claude ou Cursor, essayez notre optimiseur de prompts gratuit. Et pour un aperçu des meilleurs outils de codage, consultez Claude Code vs Codex.

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