5 erreurs de sécurité que tout développeur Vibe commet (et comment les corriger)

Le code généré par l'IA fonctionne. Il s'exécute. Il semble correct. Il est aussi livré avec les mêmes cinq vulnérabilités de sécurité dans presque tous les projets. Ce ne sont pas des risques théoriques — ce sont les failles spécifiques qui apparaissent dans presque tous les codebases produits par Claude, Cursor, Replit, ou Copilot quand vous ne demandez pas explicitement la sécurité.

J'ai audité des dizaines de projets codés au feeling au cours de l'année passée, et les mêmes cinq erreurs apparaissent dans au moins 80% d'entre eux. Chacune prend moins de 30 minutes à corriger. Voici ce qu'il faut chercher et exactement comment le corriger.

Erreur 1 : Clés API codées en dur dans le code frontend

Comment cela arrive : Vous dites à Claude « se connecter à Supabase » ou « ajouter les paiements Stripe », et il génère du code avec la clé API collée directement dans un composant React. Le code fonctionne parfaitement — et votre clé secrète est visible par quiconque ouvre les DevTools du navigateur et vérifie l'onglet Network ou la source JavaScript.

Pourquoi c'est dangereux : Votre clé de rôle de service Supabase contourne toute la sécurité de la base de données. Votre clé secrète Stripe permet à quelqu'un de facturer des cartes ou d'émettre des remboursements. Votre clé OpenAI permet à quelqu'un d'accumuler des milliers en appels API sur votre compte. Les bots scannent activement les dépôts GitHub publics et les sites déployés à la recherche de clés exposées.

La solution : Déplacez chaque secret dans des variables d'environnement. Dans Next.js, seules les variables commençant par NEXT_PUBLIC_ atteignent le navigateur. Toute clé qui accorde l'accès en écriture, l'accès administrateur, ou l'accès financier doit être côté serveur uniquement.

Après avoir déplacé les clés vers .env.local, recherchez vos anciennes valeurs de clé dans tout votre codebase pour vous assurer qu'elles sont parties. Puis vérifiez votre historique Git — si la clé a déjà été committée, elle est toujours dans votre historique de dépôt même si vous l'avez supprimée. Régénérez (faites tourner) toute clé qui a jamais été exposée, même brièvement.

Temps pour corriger : 15-30 minutes.

Erreur 2 : Tables Supabase sans sécurité au niveau des lignes

Comment cela arrive : L'IA génère des requêtes de création de tables Supabase et des opérations CRUD, mais n'active pas Row-Level Security (RLS). Par défaut, les tables Supabase avec RLS désactivée sont entièrement accessibles à quiconque dispose de l'URL de votre projet et de la clé anon — toutes deux publiques (et devraient l'être).

Pourquoi c'est dangereux : Sans RLS, l'utilisateur A peut interroger les données de l'utilisateur B. Un simple appel fetch depuis la console du navigateur peut extraire chaque ligne de chaque table. Votre base de données entière est effectivement publique.

Comment le repérer : Allez dans votre tableau de bord Supabase → Table Editor. Si une table affiche « RLS Disabled », vous avez ce problème. Vérifiez également si votre code côté client utilise la clé service_role au lieu de la clé anon — c'est encore pire.

La solution : Activez RLS sur chaque table. Puis créez des politiques qui correspondent aux modèles d'accès de votre application. La politique la plus courante : les utilisateurs ne peuvent SELECT, INSERT, UPDATE et DELETE que les lignes où auth.uid() = user_id. Testez en vous connectant en tant qu'un utilisateur et en tentant d'accéder aux données d'un autre utilisateur via l'API REST Supabase.

Temps pour corriger : 30-60 minutes selon le nombre de tables.

Erreur 3 : Pas de validation des entrées sur les formulaires ou les routes API

Comment cela arrive : L'IA génère des formulaires qui acceptent n'importe quelle entrée et des routes API qui font confiance à toutes les données qui arrivent. Le formulaire a un attribut « required » en HTML, mais pas de validation côté serveur. Quelqu'un contourne le formulaire entièrement en envoyant une requête API directe avec la charge utile qu'il souhaite.

Pourquoi c'est dangereux : Sans validation côté serveur, les attaquants peuvent injecter des scripts dans votre base de données (XSS stocké), envoyer des charges utiles surdimensionnées qui crashent votre serveur, ou soumettre des données qui cassent la logique de votre application (comme un prix négatif ou un champ e-mail contenant du SQL).

Comment le repérer : Ouvrez n'importe quelle route API ou action serveur dans votre codebase. Si elle utilise req.body ou les données de formulaire sans vérifier la forme, le type et la longueur de chaque champ, vous avez ce problème.

La solution : Ajoutez une validation côté serveur à chaque endpoint en utilisant une bibliothèque de validation de schéma. Zod est la norme pour les projets TypeScript :

import { z } from 'zod';

const taskSchema = z.object({
  title: z.string().min(1).max(200),
  description: z.string().max(2000).optional(),
  priority: z.enum(['low', 'medium', 'high']),
});

// In your API route:
const parsed = taskSchema.safeParse(req.body);
if (!parsed.success) {
  return Response.json({ error: parsed.error }, { status: 400 });
}

Pour tout champ qui s'affiche en HTML (commentaires, descriptions, bios), désinfectez aussi la sortie avec DOMPurify avant de l'afficher.

Temps pour corriger : 30-60 minutes.

Erreur 4 : Pas de limitation de débit sur les endpoints API

Comment cela arrive : L'IA n'ajoute jamais de limitation de débit sauf si vous le demandez. Chaque route API que votre application expose peut être frappée des milliers de fois par seconde par n'importe qui disposant d'un script.

Pourquoi c'est dangereux : Sans limitation de débit, quelqu'un peut forcer brute votre endpoint de connexion, scraper votre base de données en frappant les endpoints de liste à plusieurs reprises, surcharger votre serveur (déni de service), ou épuiser votre quota API si vos endpoints appellent des services externes comme OpenAI ou Stripe.

Comment le repérer : Si aucune de vos routes API ne vérifie combien de requêtes une seule IP ou un seul utilisateur a faites récemment, vous n'avez pas de limitation de débit.

La solution : L'approche la plus simple pour les applications hébergées sur Vercel est un limiteur de débit en mémoire pour le développement et un basé sur Redis pour la production. Le Edge Middleware de Vercel peut gérer une limitation de débit basique. Upstash Redis (tier gratuit) avec @upstash/ratelimit vous donne une limitation de débit de qualité production en peu de code.

Un point de départ raisonnable : 60 requêtes par minute pour les utilisateurs authentifiés, 20 par minute pour les utilisateurs non authentifiés, et 5 par minute pour les endpoints de connexion/inscription (pour prévenir le forçage brute).

Temps pour corriger : 20-45 minutes.

Erreur 5 : Vérifications d'authentification manquantes sur les pages et les API protégées

Comment cela arrive : L'IA génère une belle page tableau de bord et des routes API qui retournent les données utilisateur, mais n'ajoute pas de middleware pour vérifier que l'utilisateur est vraiment connecté. La page « fonctionne » car lors du développement vous êtes toujours connecté. En production, quelqu'un peut accéder à l'URL du tableau de bord directement sans se connecter, ou frapper l'endpoint API et obtenir des données en retour.

Pourquoi c'est dangereux : L'accès non authentifié aux pages protégées signifie que n'importe qui peut voir les tableaux de bord utilisateur, les panneaux d'administration, ou les données privées en devinant simplement l'URL. Les routes API non protégées signifient que n'importe quel outil comme Postman ou curl peut extraire les données sans identifiants.

Comment le repérer : Ouvrez une fenêtre de navigateur incognito (non connecté) et naviguez directement vers vos URLs de tableau de bord, paramètres, ou administration. Si vous pouvez voir du contenu sans être redirigé vers une page de connexion, vous avez ce problème. Ensuite, essayez de frapper vos routes API directement — si elles retournent des données sans un cookie de session valide ou un token d'authentification, celles-ci sont aussi non protégées.

La solution : Ajoutez un middleware d'authentification qui s'exécute avant chaque route protégée. Dans Next.js App Router, créez un middleware.ts à la racine de votre projet :

import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export function middleware(request: NextRequest) {
  const session = request.cookies.get('session');
  if (!session) {
    return NextResponse.redirect(new URL('/login', request.url));
  }
  return NextResponse.next();
}

export const config = {
  matcher: ['/dashboard/:path*', '/settings/:path*', '/api/protected/:path*'],
};

Adaptez le matcher pour couvrir chaque route qui devrait nécessiter une authentification. Testez en incognito après l'implémentation.

Temps pour corriger : 15-30 minutes.

Comment prévenir ces erreurs dans les projets futurs

Le schéma est clair : l'IA génère du code qui fonctionne fonctionnellement mais saute la sécurité parce que vous ne l'aviez pas demandée. La solution est de la demander d'emblée.

Ajoutez ceci à la fin de votre prompt initial pour tout projet codé au feeling :

EXIGENCES DE SÉCURITÉ :
- Tous les secrets dans des variables d'environnement (jamais codés en dur)
- RLS Supabase activée sur toutes les tables avec des politiques par utilisateur
- Validation des entrées côté serveur sur chaque route API (utiliser Zod)
- Limitation de débit sur tous les endpoints publics
- Middleware d'authentification sur toutes les routes protégées
- Pas de clé de rôle de service dans le code côté client

Cela n'attrapera pas tout, mais cela élimine les cinq vulnérabilités les plus courantes au premier passage au lieu de nécessiter un nettoyage plus tard.

Si vous voulez mieux maîtriser l'écriture de prompts qui produisent du code plus sécurisé dès le départ, notre optimiseur de prompt gratuit peut vous aider à structurer vos instructions. Et pour un guide de sécurité complet, consultez notre guide étape par étape : Comment sécuriser une application codée au feeling avant de la donner aux clients.

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