Les vulnérabilités du code généré par l'IA — Ce que vous déployez sans le savoir

Une étude a révélé que le code généré par l'IA est 1,7x plus susceptible d'avoir des problèmes majeurs et 2,74x plus enclin aux vulnérabilités de sécurité que le code écrit par l'homme. Si vous avez construit quelque chose avec Cursor, Claude Code ou GitHub Copilot, votre projet a probablement au moins l'une des cinq failles de sécurité les plus courantes. Voici ce qu'elles sont et comment les trouver.

Pourquoi le code IA est vulnérable

Les outils de codage IA optimisent pour « ça marche ? » et non « c'est sécurisé ? » Quand vous demandez à Cursor « ajoute l'authentification des utilisateurs », il génère du code qui authentifie les utilisateurs. Il n'ajoute pas automatiquement la limitation de débit, l'assainissement des entrées, la protection CSRF ou la gestion sécurisée des sessions — parce que vous n'avez pas demandé ces choses.

L'IA écrit exactement ce que vous décrivez. La sécurité nécessite de décrire des choses auxquelles vous ne pensez pas naturellement — les cas limites, les entrées malveillantes, les schémas d'accès non autorisé. Si ce n'est pas dans votre prompt, ce n'est pas dans votre code.

Les 5 vulnérabilités les plus courantes

1. Clés API en dur dans le code frontend. L'IA place fréquemment les clés API directement dans le JavaScript côté client ou les composants React. N'importe qui peut ouvrir les DevTools du navigateur et les voir. Correction : Déplacer toutes les clés vers des variables d'environnement (fichiers .env) et les accéder uniquement côté serveur. Temps : 15 minutes.

2. Pas de sécurité au niveau des lignes sur les bases de données. Si vous utilisez Supabase (courant en vibe coding), le code généré par l'IA donne souvent à chaque utilisateur authentifié l'accès aux données de tous les autres utilisateurs. Correction : Activer la sécurité au niveau des lignes et ajouter des politiques par utilisateur. Temps : 30 minutes.

3. Pas de validation des entrées côté serveur. Les formulaires acceptent n'importe quoi — des scripts, des charges utiles trop volumineux, des tentatives d'injection SQL. L'IA ajoute la validation côté client (que les utilisateurs peuvent contourner) mais ignore la validation côté serveur. Correction : Ajouter des schémas Zod ou une validation similaire sur chaque endpoint API. Temps : 30 minutes par endpoint.

4. Pas de limitation de débit. N'importe qui peut frapper votre API 1 000 fois par seconde. Pas de limitation, pas de protection contre les abus. Correction : Ajouter une limitation de débit via Upstash Redis ou similaire. Temps : 20 minutes.

5. Routes non protégées. Les pages de tableau de bord, les panneaux d'administration et les endpoints de données utilisateur se chargent sans vérifier si l'utilisateur est connecté. Correction : Ajouter un middleware d'authentification à chaque route protégée. Temps : 15 minutes.

Comment auditer votre projet

Parcourez cette liste de contrôle pour tout projet construit avec des outils de codage IA :

Recherchez dans tout votre codebase les clés en dur. Exécutez : grep -r "sk-" . && grep -r "api_key" . && grep -r "secret" . dans le répertoire de votre projet. Toute correspondance dans les fichiers frontend constitue des vulnérabilités critiques.

Vérifiez chaque endpoint API pour la validation des entrées. Ouvrez chaque fichier de route API. S'il utilise directement req.body sans validation, il est vulnérable.

Vérifiez la sécurité de la base de données. Si vous utilisez Supabase, vérifiez l'onglet Authentication → Policies. S'il n'y a pas de politiques RLS, chaque utilisateur peut voir les données de tous les autres utilisateurs.

Testez l'authentification sur chaque page. Ouvrez votre navigateur en mode incognito (non connecté) et accédez à chaque page de votre application. Si une page de tableau de bord ou une page spécifique à l'utilisateur se charge, cette route n'est pas protégée.

Vérifiez la limitation de débit. Essayez de frapper votre endpoint API 100 fois en succession rapide en utilisant un simple script. Si les 100 réussissent, vous n'avez pas de limitation de débit.

Pour une liste de contrôle de sécurité complète, consultez notre guide complet pour sécuriser les applications codées à la vibe. Pour les erreurs les plus courantes et leurs corrections, lisez 5 erreurs de sécurité que chaque vibe coder commet.

Le changement de mentalité

L'IA écrit du code qui marche. Vous devez vous assurer que le code est sûr. Ce sont deux compétences différentes. Chaque prompt envoyé à un outil de codage IA doit inclure les exigences de sécurité aux côtés des exigences fonctionnelles. « Ajoute l'authentification des utilisateurs avec limitation de débit, validation des entrées et routes protégées » produit un code beaucoup plus sécurisé que « ajoute l'authentification des utilisateurs ».

Notre Prompt Optimizer peut vous aider à ajouter ces spécifications de sécurité à n'importe quel prompt de codage automatiquement.

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. Voir notre politique de divulgation complète.