Code généré par l'IA : 10 failles de sécurité à vérifier avant de déployer

Les assistants de code — Claude Code, Copilot, Cursor, Gemini CLI — ont transformé la vitesse de développement. Le « vibe coding » permet même à des non-développeurs de livrer une application. Mais un code qui fonctionne n'est pas un code sûr : le modèle optimise pour que la fonctionnalité marche, rarement pour qu'elle résiste à un attaquant. Voici les 10 failles à rechercher systématiquement.

1. Des secrets écrits en dur

Clés API, mots de passe de base de données, jetons insérés directement dans le code « pour tester », puis commités. Vérifiez qu'ils passent par les variables d'environnement (.env jamais versionné) et scannez le dépôt avec un outil de détection de secrets.

2. Des requêtes SQL construites par concaténation

Un DB::select("SELECT * FROM users WHERE email = '$email'") fonctionne parfaitement… et ouvre une injection SQL. Exigez l'Eloquent, le query builder ou des requêtes préparées avec paramètres liés, y compris dans whereRaw et orderByRaw.

3. Des contrôles d'autorisation absents

C'est la faille la plus fréquente : la route vérifie que l'utilisateur est connecté, mais pas qu'il a le droit d'accéder à cette ressource. Changer l'identifiant dans l'URL donne accès aux données d'un autre client (IDOR). Chaque action doit passer par une policy ou un Gate.

4. L'assignation de masse non protégée

User::create($request->all()) permet à un utilisateur d'envoyer is_admin=1. Utilisez $request->validated() et des $fillable explicites.

5. Des affichages non échappés (XSS)

Pour « afficher correctement le HTML », l'IA remplace volontiers {{ }} par {!! !!} dans Blade, ou utilise v-html dans Vue. Toute donnée utilisateur affichée ainsi devient une faille XSS.

6. Des uploads de fichiers sans contrôle

Pas de validation du type réel, pas de limite de taille, stockage dans un dossier public exécutable : un fichier PHP déguisé en image suffit à prendre le contrôle du serveur. Validez (mimes, max), renommez et stockez hors du dossier public.

7. Des packages inventés ou douteux

Les modèles « hallucinent » parfois des noms de packages plausibles. Des attaquants publient justement des packages malveillants sous ces noms (on parle de slopsquatting). Vérifiez l'existence, l'éditeur et la popularité de chaque dépendance proposée, comme expliqué dans notre checklist anti-supply chain.

8. Une configuration de débogage en production

APP_DEBUG=true, routes de test oubliées, CORS ouvert à *, pages d'administration sans protection : l'IA configure pour que « ça marche en local ». Relisez la configuration de production séparément.

9. Des validations seulement côté client

Un formulaire validé en JavaScript mais pas côté serveur se contourne avec un simple outil comme cURL. Chaque entrée doit être validée côté serveur avec une Form Request.

10. L'absence de limitation de débit

Connexion, réinitialisation de mot de passe, envoi de SMS ou d'e-mails, appels à une API payante d'IA : sans throttle, ces routes permettent le brute force ou font exploser la facture.

Une méthode de revue efficace

1. Donnez des règles à l'assistant : dans le fichier d'instructions du projet (CLAUDE.md ou équivalent), listez vos exigences de sécurité. Voir notre article sur Laravel Boost et les bonnes pratiques.
2. Relisez chaque diff comme celui d'un développeur junior : l'IA écrit vite, vous restez responsable.
3. Automatisez : analyse statique (PHPStan/Larastan), détection de secrets, composer audit, tests d'autorisation dans la CI.
4. Demandez une revue de sécurité dédiée : un second passage de l'IA, centré uniquement sur la sécurité, attrape une partie des problèmes du premier.
5. Testez les cas d'abus, pas seulement les cas nominaux : accès à la ressource d'un autre utilisateur, entrée malformée, fichier piégé.

Conclusion

L'IA ne rend pas le code moins sûr par nature, mais elle produit plus de code, plus vite, avec moins de relecture. La parade n'est pas de renoncer aux assistants, c'est d'adapter le processus : des règles explicites, une revue systématique et des contrôles automatiques. Pour une base solide, voir aussi notre guide API REST Laravel avec Sanctum.