Guide gratuit

25 erreurs que les outils de code IA commettent encore en production.

Q: RLS désactivé sur une table

Pourquoi ça arrive: Supabase désactive RLS par défaut sur les nouvelles tables. Un vibe-coder qui ne connaît pas ce détail expose toute la table à quiconque possède la clé anon, publique par design. Comment corriger: ALTER TABLE nom_table ENABLE ROW LEVEL SECURITY; puis écrire des policies explicites.

Q: Policy RLS trop permissive (USING (true))

Pourquoi ça arrive: En développement, un USING (true) fait disparaître les erreurs de permission. Pratique pour avancer vite, oublié avant le lancement. Comment corriger: Remplacer par une condition liée à auth.uid(), par exemple USING (auth.uid() = user_id).

Q: Policy vérifiée côté SELECT mais pas côté UPDATE ou DELETE

Pourquoi ça arrive: Les générateurs IA créent souvent une policy de lecture correcte, mais oublient de dupliquer la même logique sur les autres opérations. INSERT, UPDATE et DELETE nécessitent chacun leur propre policy. Comment corriger: Une policy par opération (FOR SELECT, FOR UPDATE, FOR DELETE, FOR INSERT), jamais une seule policy générique FOR ALL mal pensée.

Q: Relations (foreign keys) contournant les policies

Pourquoi ça arrive: Une table protégée référence une table non protégée. L'attaquant passe par la table faible pour atteindre les données de la table forte via une jointure. Comment corriger: RLS activé et cohérent sur l'intégralité du schéma, pas table par table isolément.

Q: Fonctions RPC (SECURITY DEFINER) mal scopées

Pourquoi ça arrive: Les fonctions PostgreSQL exposées via l'API Supabase en SECURITY DEFINER s'exécutent avec les droits du créateur, pas de l'appelant. Ça contourne RLS si mal écrit. Comment corriger: Ajouter un contrôle explicite de auth.uid() à l'intérieur de la fonction, ne jamais supposer que RLS s'applique automatiquement.

Q: Clé service_role utilisée côté client

Pourquoi ça arrive: La clé service_role contourne RLS entièrement. Un développeur pressé l'utilise pour que ça marche pendant les tests, et l'oublie dans le code final. Comment corriger: La clé service_role ne doit exister que côté serveur (Edge Functions, API routes), jamais dans une variable exposée au navigateur.

Q: Clés API tierces exposées dans le bundle client

Pourquoi ça arrive: Confusion entre variables d'environnement publiques (NEXT_PUBLIC_*) et privées. Un préfixe mal choisi expose une clé secrète au navigateur. Comment corriger: Toute clé secrète doit rester sans préfixe NEXT_PUBLIC_, appelée uniquement depuis le serveur.

Q: Secrets commités dans l'historique Git

Pourquoi ça arrive: Un .env ajouté par erreur au premier commit, puis supprimé, mais qui reste dans l'historique Git, récupérable. Comment corriger: Rotation immédiate de toute clé trouvée (changer la clé, pas juste la supprimer du code), .gitignore correct dès le départ.

Q: Variables d'environnement absentes du .env.example

Pourquoi ça arrive: Sans documentation claire de quelles variables sont publiques ou privées, chaque nouvel environnement répète les mêmes erreurs. Comment corriger: Documenter explicitement chaque variable avec un commentaire "PUBLIC" ou "SECRET, SERVEUR UNIQUEMENT".

Q: Bucket de stockage public par défaut

Pourquoi ça arrive: Supabase Storage propose des buckets publics pour simplifier l'affichage d'images. Un développeur choisit "public" pour que ça marche vite, y compris pour des documents sensibles. Comment corriger: Bucket privé par défaut, plus une policy d'accès signée (createSignedUrl) pour tout contenu non destiné au grand public.

La méthodologie exacte que nous utilisons en mission, en accès libre. Six catégories, vingt-cinq failles concrètes : pourquoi elles arrivent, comment les tester, comment les corriger.

Row-Level Security (RLS) et contrôle d'accès aux données

RLS désactivé sur une tableCritique

Critique

Pourquoi ça arrive

Supabase désactive RLS par défaut sur les nouvelles tables. Un vibe-coder qui ne connaît pas ce détail expose toute la table à quiconque possède la clé anon, publique par design.

Comment tester

SELECT tablename FROM pg_tables WHERE schemaname = 'public' AND rowsecurity = false;

Comment corriger

ALTER TABLE nom_table ENABLE ROW LEVEL SECURITY; puis écrire des policies explicites.

Sévérité type

Critique

Policy RLS trop permissive (USING (true))Critique

Critique

Pourquoi ça arrive

En développement, un USING (true) fait disparaître les erreurs de permission. Pratique pour avancer vite, oublié avant le lancement.

Comment tester

Audit manuel de chaque policy dans le dashboard Supabase, ou via SELECT * FROM pg_policies;

Comment corriger

Remplacer par une condition liée à auth.uid(), par exemple USING (auth.uid() = user_id).

Sévérité type

Critique

Policy vérifiée côté SELECT mais pas côté UPDATE ou DELETEÉlevée

Élevée

Pourquoi ça arrive

Les générateurs IA créent souvent une policy de lecture correcte, mais oublient de dupliquer la même logique sur les autres opérations. INSERT, UPDATE et DELETE nécessitent chacun leur propre policy.

Comment tester

Créer deux comptes de test, tenter une requête UPDATE ou DELETE du compte A sur une ligne du compte B avec la clé anon.

Comment corriger

Une policy par opération (FOR SELECT, FOR UPDATE, FOR DELETE, FOR INSERT), jamais une seule policy générique FOR ALL mal pensée.

Sévérité type

Élevée

Relations (foreign keys) contournant les policiesÉlevée

Élevée

Pourquoi ça arrive

Une table protégée référence une table non protégée. L'attaquant passe par la table faible pour atteindre les données de la table forte via une jointure.

Comment tester

Cartographier toutes les foreign keys, vérifier RLS sur chaque table liée, pas seulement la table principale.

Comment corriger

RLS activé et cohérent sur l'intégralité du schéma, pas table par table isolément.

Sévérité type

Élevée

Fonctions RPC (SECURITY DEFINER) mal scopéesCritique

Critique

Pourquoi ça arrive

Les fonctions PostgreSQL exposées via l'API Supabase en SECURITY DEFINER s'exécutent avec les droits du créateur, pas de l'appelant. Ça contourne RLS si mal écrit.

Comment tester

Lister les fonctions RPC exposées, vérifier si elles filtrent bien par utilisateur appelant.

Comment corriger

Ajouter un contrôle explicite de auth.uid() à l'intérieur de la fonction, ne jamais supposer que RLS s'applique automatiquement.

Sévérité type

Critique

Secrets et clés exposées

Clé service_role utilisée côté clientCritique

Critique

Pourquoi ça arrive

La clé service_role contourne RLS entièrement. Un développeur pressé l'utilise pour que ça marche pendant les tests, et l'oublie dans le code final.

Comment tester

Grep du code source et du bundle JS produit pour "service_role" ou le pattern de clé JWT Supabase.

Comment corriger

La clé service_role ne doit exister que côté serveur (Edge Functions, API routes), jamais dans une variable exposée au navigateur.

Sévérité type

Critique

Clés API tierces exposées dans le bundle clientCritique

Critique

Pourquoi ça arrive

Confusion entre variables d'environnement publiques (NEXT_PUBLIC_*) et privées. Un préfixe mal choisi expose une clé secrète au navigateur.

Comment tester

Inspecter le bundle JS final produit, chercher les patterns de clé (sk_live_, sk-, etc.).

Comment corriger

Toute clé secrète doit rester sans préfixe NEXT_PUBLIC_, appelée uniquement depuis le serveur.

Sévérité type

Critique

Secrets commités dans l'historique GitÉlevée

Élevée à Critique selon la clé

Pourquoi ça arrive

Un .env ajouté par erreur au premier commit, puis supprimé, mais qui reste dans l'historique Git, récupérable.

Comment tester

Scan avec gitleaks ou trufflehog sur tout l'historique, pas seulement le code actuel.

Comment corriger

Rotation immédiate de toute clé trouvée (changer la clé, pas juste la supprimer du code), .gitignore correct dès le départ.

Sévérité type

Élevée à Critique selon la clé

Variables d'environnement absentes du .env.exampleFaible

Faible, mais facteur aggravant pour les autres failles

Pourquoi ça arrive

Sans documentation claire de quelles variables sont publiques ou privées, chaque nouvel environnement répète les mêmes erreurs.

Comment tester

Vérifier la cohérence entre .env.example, la documentation du projet et l'usage réel dans le code.

Comment corriger

Documenter explicitement chaque variable avec un commentaire "PUBLIC" ou "SECRET, SERVEUR UNIQUEMENT".

Sévérité type

Faible, mais facteur aggravant pour les autres failles

Stockage (Storage buckets)

Bucket de stockage public par défautÉlevée

Élevée

Pourquoi ça arrive

Supabase Storage propose des buckets publics pour simplifier l'affichage d'images. Un développeur choisit "public" pour que ça marche vite, y compris pour des documents sensibles.

Comment tester

Lister les buckets et leur statut public ou privé, tenter un accès direct par URL sans authentification.

Comment corriger

Bucket privé par défaut, plus une policy d'accès signée (createSignedUrl) pour tout contenu non destiné au grand public.

Sévérité type

Élevée

URLs de fichiers prévisiblesMoyenne

Moyenne à Élevée selon la sensibilité du contenu

Pourquoi ça arrive

Nommer les fichiers uploadés avec un ID auto-incrémenté ou un nom original non aléatoire permet de deviner ou d'énumérer les fichiers d'autres utilisateurs.

Comment tester

Uploader un fichier, observer le pattern de nommage, tenter d'incrémenter ou de deviner d'autres URLs.

Comment corriger

Noms de fichiers en UUID aléatoire, jamais liés à un ID interne devinable.

Sévérité type

Moyenne à Élevée selon la sensibilité du contenu

Policies de bucket absentes malgré un bucket "privé"Élevée

Élevée

Pourquoi ça arrive

Marquer un bucket comme privé dans l'interface ne suffit pas. Sans policy RLS sur storage.objects, l'accès peut rester mal contrôlé selon la configuration.

Comment tester

Vérifier les policies RLS spécifiquement sur le schéma storage, pas seulement sur les tables métier.

Comment corriger

Policies explicites sur storage.objects liées à auth.uid() ou au propriétaire du fichier.

Sévérité type

Élevée

Authentification et gestion de session

Absence de limitation de tentatives sur le loginÉlevée

Élevée

Pourquoi ça arrive

Les templates générés par IA implémentent rarement une protection anti-bruteforce par défaut. Ce n'est pas visible tant que personne n'attaque.

Comment tester

Scripter une série de tentatives de connexion rapides, observer si un blocage ou un délai intervient.

Comment corriger

Rate limiting au niveau middleware ou via un service dédié (Supabase Auth propose des options, sinon Upstash ou Redis).

Sévérité type

Élevée

Réinitialisation de mot de passe non sécuriséeÉlevée

Élevée

Pourquoi ça arrive

Token de reset trop court, non expirant, ou réutilisable plusieurs fois.

Comment tester

Générer un lien de reset, vérifier son expiration réelle, tenter de le réutiliser après usage.

Comment corriger

Token à usage unique, expiration courte (15 à 30 minutes), invalidation après utilisation.

Sévérité type

Élevée

Rôles et permissions vérifiés uniquement côté clientCritique

Critique

Pourquoi ça arrive

Cacher un bouton "Admin" dans l'interface donne l'illusion de sécurité, mais l'API sous-jacente reste accessible directement.

Comment tester

Appeler directement les endpoints ou actions admin via un client HTTP avec un compte non-admin, en ignorant l'interface.

Comment corriger

Chaque vérification de rôle doit être dupliquée côté serveur (API route, Edge Function, ou policy RLS), jamais seulement en conditionnel React.

Sévérité type

Critique

Session ou JWT transmis dans l'URLÉlevée

Élevée

Pourquoi ça arrive

Simplification de debug ou d'implémentation : un token passé en paramètre de requête plutôt qu'en header ou cookie sécurisé.

Comment tester

Observer les requêtes réseau pendant l'authentification, chercher des tokens dans les paramètres de requête.

Comment corriger

Tokens uniquement en header Authorization ou cookie httpOnly et secure, jamais en URL.

Sévérité type

Élevée

Absence de vérification d'email avant activation du compteMoyenne

Moyenne

Pourquoi ça arrive

Simplifie l'onboarding pendant le développement, oublié en configuration de production.

Comment tester

Créer un compte avec un email non vérifié, tenter d'accéder aux fonctionnalités.

Comment corriger

Activer la confirmation email obligatoire dans les paramètres d'authentification avant le lancement public.

Sévérité type

Moyenne

Surface API et validation des entrées

Endpoints ou Edge Functions sans vérification d'authentificationCritique

Critique

Pourquoi ça arrive

Un endpoint créé pour un test interne, jamais protégé, oublié en production.

Comment tester

Lister tous les endpoints et fonctions déployés, tester chacun sans header d'authentification.

Comment corriger

Middleware d'authentification systématique, vérification explicite en début de chaque fonction.

Sévérité type

Critique

Absence de validation des entrées côté serveurÉlevée

Élevée

Pourquoi ça arrive

La validation est faite côté React (formulaires) mais jamais dupliquée côté API. Un attaquant contourne l'interface et envoie des données directement.

Comment tester

Envoyer des payloads malformés ou inattendus directement à l'API (types incorrects, champs manquants, valeurs hors limites).

Comment corriger

Validation systématique côté serveur avec une librairie type Zod, jamais de confiance aveugle dans les données reçues.

Sévérité type

Élevée

Configuration CORS trop permissiveMoyenne

Moyenne

Pourquoi ça arrive

Access-Control-Allow-Origin défini sur un joker résout rapidement les erreurs CORS en développement, laissé tel quel en production.

Comment tester

Inspecter les headers de réponse des endpoints API.

Comment corriger

Liste blanche explicite des domaines autorisés en production.

Sévérité type

Moyenne

Références directes non sécurisées (IDOR) sur les endpoints RESTCritique

Critique

Pourquoi ça arrive

Un endpoint du type /api/orders/123 ne vérifie pas que l'utilisateur connecté est bien propriétaire de la commande, juste que l'identifiant existe.

Comment tester

Accéder à des ressources d'un autre utilisateur en changeant simplement l'identifiant dans l'URL ou la requête.

Comment corriger

Vérification systématique de propriété sur chaque requête, jamais seulement sur l'identifiant de ressource.

Sévérité type

Critique

Intégrations tierces et spécificités IA

Webhooks sans vérification de signatureÉlevée

Élevée à Critique, impact financier direct si Stripe

Pourquoi ça arrive

Un gestionnaire de webhook créé rapidement traite toute requête reçue sur l'URL sans vérifier qu'elle vient réellement du fournisseur.

Comment tester

Envoyer une requête forgée à l'endpoint webhook sans signature valide, observer si elle est traitée.

Comment corriger

Vérification systématique de la signature cryptographique fournie par le service tiers avant tout traitement.

Sévérité type

Élevée à Critique, impact financier direct si Stripe

Injection de prompt sur les fonctionnalités IAMoyenne

Moyenne à Élevée selon les actions accessibles via le LLM

Pourquoi ça arrive

Une entrée utilisateur est directement concaténée dans un prompt envoyé à un LLM, permettant à l'utilisateur de manipuler les instructions système.

Comment tester

Tenter d'injecter des instructions du type "ignore les instructions précédentes et..." dans les champs qui alimentent un prompt IA.

Comment corriger

Séparation claire entre instructions système et entrée utilisateur, validation et filtrage des entrées, limitation des actions que le LLM peut déclencher automatiquement.

Sévérité type

Moyenne à Élevée selon les actions accessibles via le LLM

Clé API du LLM appelée depuis le clientÉlevée

Élevée, risque financier en cas d'abus de la clé

Pourquoi ça arrive

Pour prototyper vite, l'appel à l'API IA est fait directement depuis le composant plutôt que via une route serveur. Ça expose la clé et permet un usage non contrôlé.

Comment tester

Inspecter les requêtes réseau du navigateur pendant l'usage d'une fonctionnalité IA, chercher des appels directs à des API IA tierces.

Comment corriger

Toute génération IA passe par une route serveur qui détient la clé, avec limitation d'usage par utilisateur.

Sévérité type

Élevée, risque financier en cas d'abus de la clé

Dépendances npm obsolètes ou vulnérablesVariable selon la faille

Variable selon la faille, de Faible à Critique

Pourquoi ça arrive

Les outils IA génèrent du code fonctionnel mais ne mettent pas à jour proactivement les dépendances, certaines avec des failles connues.

Comment tester

npm audit ou pnpm audit régulièrement, comparaison avec la base des vulnérabilités connues.

Comment corriger

Mise à jour régulière, npm audit fix, surveillance continue via un outil type Dependabot.

Sévérité type

Variable selon la faille, de Faible à Critique

Et ensuite ?

Vous venez de repérer une de ces failles dans votre projet ?

Cette liste est notre méthodologie de test, condensée. Une revue complète va plus loin : accès manuel, priorisation par impact business, et un rapport que vous pouvez transmettre tel quel à votre équipe.

Réserver ma revue