Sécuriser le code généré par IA

Un assistant IA optimise une chose : que le code fasse ce que vous avez demandé. Vous avez demandé un formulaire de contact, vous obtenez un formulaire de contact qui fonctionne. Vous n'avez pas demandé qu'il résiste à quelqu'un qui envoie dix mille requêtes par minute avec une charge utile malveillante, donc vous ne l'obtenez pas.

Ce n'est pas un défaut du modèle, c'est une conséquence de son entraînement. Il a appris sur du code public : des dépôts d'exemples, des réponses de forums, des tutoriels. Ce corpus est massivement composé de code écrit pour illustrer un concept, pas pour survivre à Internet.

Pourquoi le code généré est vulnérable par défaut

Trois mécanismes se combinent. D'abord le biais du corpus déjà évoqué. Ensuite le fait que la sécurité est presque toujours du code en plus : une validation, une vérification de droits, une limite de débit. Un modèle qui vise la réponse la plus probable produit la version courte, qui est la version non sécurisée.

Le troisième mécanisme est le plus sournois : vous ne voyez pas ce qui manque. Une faille d'injection ne ressemble à rien à l'écran. Le formulaire s'affiche, l'enregistrement fonctionne, les tests passent. L'absence de contrôle est invisible tant que personne ne cherche à en profiter.

Les failles qui reviennent le plus

Secrets écrits en dur

C'est la plus fréquente et la plus coûteuse. Quand vous demandez une connexion à une base ou un appel d'API, le modèle produit un exemple complet, donc avec une valeur à la place de la clé. Si vous collez votre vraie clé pour tester et que vous oubliez de l'extraire, elle part dans l'historique Git — et l'historique reste même après correction.

// Généré : la clé finit dans le dépôt
const client = new ApiClient("sk_live_4eC39H...");

// Attendu : la clé reste hors du code
const key = process.env.API_KEY;
if (!key) throw new Error("API_KEY manquante");
const client = new ApiClient(key);

Le réflexe à prendre : avant le premier commit d'un projet, chercher les chaînes qui ressemblent à des clés. Si une clé a déjà été poussée, la révoquer est la seule réponse — la retirer du code ne suffit pas.

Requêtes construites par concaténation

Les modèles connaissent parfaitement les requêtes paramétrées, mais produisent volontiers de la concaténation quand la requête est dynamique — un tri variable, un filtre optionnel. C'est précisément dans ces cas que l'injection devient possible.

// Vulnérable : la valeur est collée dans la requête
db.query("SELECT * FROM users WHERE email = '" + email + "'");

// Sûr : la valeur est transmise séparément
db.query("SELECT * FROM users WHERE email = $1", [email]);

Le signal en relecture est simple : toute requête contenant un opérateur de concaténation ou une interpolation de variable mérite un second regard.

Validation d'entrée absente ou côté client seulement

Une IA à qui l'on demande un formulaire ajoute spontanément la validation visible : champ requis, format d'e-mail. Cette validation vit dans le navigateur, où n'importe qui peut la contourner en envoyant la requête directement. La validation qui compte est celle du serveur, et elle n'est presque jamais générée sans demande explicite.

Demandez systématiquement une validation serveur avec un schéma typé, et vérifiez qu'elle rejette aussi les cas que vous n'aviez pas prévus : champ absent, type inattendu, chaîne de dix mégaoctets.

Dépendances qui n'existent pas

Un modèle peut inventer un paquet au nom plausible qui n'existe pas. Le phénomène a un nom, le slopsquatting, parce que des attaquants ont compris qu'il suffit d'observer les noms hallucinés récurrents et de publier de vrais paquets malveillants sous ces noms. La commande d'installation qu'on vous suggère devient alors une porte d'entrée.

Permissions et CORS trop larges

Face à un problème de droits, le chemin le plus court est d'ouvrir en grand. Les modèles suivent ce chemin : une origine autorisée devient l'astérisque, un rôle applicatif devient le super-utilisateur de la base, un fichier devient lisible par tous. Ça résout le blocage immédiat et ça crée une exposition durable.

Un protocole de relecture qui tient en six points

Relire du code généré demande une méthode différente de la revue classique : vous ne cherchez pas une erreur dans ce qui est écrit, vous cherchez ce qui manque. Ces six questions couvrent l'essentiel.

1. Où sont les secrets ? Aucune valeur sensible ne doit apparaître dans le code, ni dans un fichier d'exemple committé.
2. Chaque entrée utilisateur est-elle validée côté serveur, avec un type et une taille maximale ?
3. Les requêtes sont-elles paramétrées, sans exception, y compris celles construites dynamiquement ?
4. Que se passe-t-il si on appelle cette route mille fois par minute ? Une limite de débit existe-t-elle ?
5. Les messages d'erreur renvoyés à l'utilisateur révèlent-ils la structure interne, un chemin de fichier ou une requête ?
6. Chaque dépendance ajoutée existe-t-elle vraiment, et depuis quand ?

Faire vérifier par la machine

La relecture humaine fatigue et laisse passer. Deux automatisations rapportent beaucoup pour un coût faible : un analyseur de dépendances qui signale les versions vulnérables à chaque installation, et un détecteur de secrets branché avant le commit, qui refuse le code contenant ce qui ressemble à une clé.

Une troisième approche marche étonnamment bien : demander à un second modèle de chercher les failles du code produit par le premier, en lui donnant explicitement le rôle d'attaquant. Une IA relit beaucoup mieux qu'elle n'écrit, parce que critiquer un code existant est un problème plus contraint que d'en produire un.