Pourquoi les agents de codage IA créent-ils sans cesse des failles de contrôle d’accès ?

Les agents de codage IA génèrent une logique d’autorisation qui compile, passe la revue et applique la mauvaise politique. Les failles de contrôle d’accès occupent la première place de l’OWASP Top 10:2025 : 100 % des applications testées présentaient une forme de cette faille, avec 1 839 701 occurrences recensées, le nombre le plus élevé de toutes les catégories de la liste.

Une partie de cette catégorie échappe par nature à l’analyse basée sur des motifs. Lorsqu’un agent omet une vérification de propriété, la règle enfreinte relève de l’application, et non d’une base de signatures. Il n’existe donc aucun motif malveillant connu auquel la comparer.

Qu’est-ce qu’une faille de contrôle d’accès ?

Une faille de contrôle d’accès survient lorsque l’application ne fait pas respecter ce qu’un utilisateur authentifié est autorisé à faire ou à voir. L’utilisateur prouve son identité, puis l’application lui donne accès à des données ou à des actions appartenant à quelqu’un d’autre. Deux cas nommés couvrent la plupart des situations rencontrées par les équipes.

1. BOLA : autorisation défaillante au niveau de l’objet

BOLA désigne l’absence de vérification que le demandeur a le droit d’accéder à l’objet précis demandé. Cette faille arrive en tête de l’OWASP API Security Top 10, ce qui la place au sommet des deux listes OWASP applicables aux applications modernes.

2. IDOR : référence directe non sécurisée à un objet

IDOR désigne la même faille, vue du côté de l’attaquant. L’application expose un identifiant interne, comme l’ID d’un enregistrement, et le remplacer par une autre valeur renvoie des données appartenant à un autre compte. Un même bug relève généralement à la fois de BOLA et d’IDOR.

OWASP a placé cette catégorie en tête de sa liste en 2021, et elle y est restée dans l’édition 2025. Ces failles sont simples. Elles conservent cette place parce qu’elles sont faciles à introduire, difficiles à détecter automatiquement et immédiatement exploitables une fois découvertes.

Pourquoi les agents de codage IA se trompent-ils si souvent sur l’autorisation ?

Le développement logiciel est passé à l’agentique, mais pas la sécurité. La sécurité des applications s’est construite autour d’analyses qui reconnaissent des motifs malveillants connus et transmettent leurs résultats à des personnes connaissant les règles du produit. Lorsqu’un agent écrit le point de terminaison, personne dans la boucle n’applique ces règles par défaut, et la faille qui en résulte ne correspond à aucun motif. Combler cet écart exige plus qu’une règle supplémentaire.

Parce que l’exigence d’autorisation n’a jamais été énoncée, et que l’agent exécute correctement la tâche qui lui a été confiée. Imaginez qu’un développeur demande à un agent de codage d’ajouter un point de terminaison qui renvoie une facture à partir de son ID. L’agent génère une route qui vérifie que l’appelant est connecté, recherche la facture à l’aide de l’identifiant fourni dans l’URL, renvoie une erreur 404 si rien ne correspond, puis transmet l’enregistrement au client.

Chacune de ces décisions est correcte au regard de la tâche formulée. Le point de terminaison authentifie l’utilisateur, gère le cas où l’enregistrement est absent et se lit facilement lors de la revue. Il permet aussi à tout utilisateur authentifié de consulter n’importe quelle facture du système en modifiant une seule valeur dans l’URL.

La correction consiste à ajouter une condition à la recherche : faire correspondre la facture à son identifiant et à l’organisation dont dépend l’appelant. Rien d’autre ne change dans le point de terminaison.

Pourquoi le code seul ne permet pas de connaître la correction

Pour savoir que la seconde version est correcte, il faut connaître trois faits qui n’apparaissent nulle part dans le code généré :

• Les factures appartiennent à des organisations.

• L’accès des utilisateurs est limité aux organisations dont ils sont membres.

• Dans ce produit, aucune lecture entre organisations n’est légitime.

Dans un autre produit, le troisième fait pourrait être faux, car certaines plateformes autorisent par conception les auditeurs, les revendeurs ou les comptes principaux à accéder aux données de plusieurs tenants. Cette règle est une caractéristique du produit, pas du langage ni du framework. Elle se trouve dans le modèle de données, dans une décision prise il y a deux ans et dans l’esprit des ingénieurs qui l’ont prise.

Les points à vérifier lors d’une revue

Un développeur de l’équipe repère généralement le problème pour une raison : il connaît le produit. Un agent qui s’appuie sur l’invite et le fichier environnant n’a pas accès à ce qui rend cette vérification nécessaire.

Deux détails méritent d’être pris en compte lors de la revue. Le premier concerne le code de réponse. En intégrant la condition de propriété à la recherche, une requête visant la facture d’une autre organisation renvoie le même 404 qu’une requête visant une facture inexistante. C’est le comportement souhaité, car un 403 confirmerait l’existence de l’enregistrement et permettrait à un attaquant d’énumérer des identifiants valides. Le deuxième concerne les données renvoyées. Renvoyer l’enregistrement stocké sans modification transmet tous ses champs ; le même gestionnaire présente donc souvent un problème d’exposition des données en plus de celui d’autorisation.

Les outils SAST peuvent-ils détecter les failles de contrôle d’accès ?

Pour les catégories de vulnérabilités qui suivent un motif, la détection est en grande partie résolue. L’autorisation fait exception, et c’est précisément là que le code généré par l’IA est le plus vulnérable. L’analyse statique repère une structure descriptible, or l’autorisation au niveau de l’objet n’en présente pas.

Prenons une injection comme point de comparaison : une vulnérabilité par injection suit une structure que l’on peut décrire. Une entrée non fiable atteint une fonction sensible sans avoir été assainie. Cette structure devient une règle, et un moteur suit les données de la source à la destination pour signaler chaque chemin correspondant.

Ce que l’analyse statique couvre dans les failles de contrôle d’accès

Les failles de contrôle d’accès constituent la plus grande catégorie de l’OWASP Top 10, mais elles ne résistent pas toutes à l’analyse. A01:2025 recense 40 CWE, dont plusieurs suivent exactement une structure traçable que l’analyse statique sait bien traiter, notamment la traversée de répertoires, les redirections ouvertes et la falsification de requêtes côté serveur. Les moteurs sémantiques modernes vont au-delà de la reconnaissance de signatures en modélisant les flux de données et l’intention du code. Lorsque le codebase suit une convention cohérente, ils peuvent signaler l’absence structurelle d’un décorateur ou d’un middleware d’autorisation sur une route.

Où se situe la limite de couverture ?

La partie qui résiste à l’analyse est plus restreinte. Il s’agit de l’autorisation au niveau de l’objet, répertoriée sous CWE-639 (contournement de l’autorisation au moyen d’une clé contrôlée par l’utilisateur), CWE-862 (autorisation manquante) et CWE-863 (autorisation incorrecte). Ici, aucun appel dangereux n’est effectué, aucune valeur non fiable n’atteint une destination qui lui est interdite et chaque ligne respecte les bonnes pratiques. Le défaut tient à l’absence d’une comparaison qu’exigent uniquement les règles propres à l’application.

Pour la signaler, un moteur devrait savoir quels champs représentent la propriété dans ce schéma, quels appelants sont autorisés et où se situe la frontière entre les tenants. Ce n’est pas une question de qualité de la règle. C’est une information absente du fichier analysé.

Les moteurs déterministes et le raisonnement doivent fonctionner de concert, et non se faire concurrence. Pour les catégories qu’ils couvrent, les moteurs renvoient toujours le même résultat, ce qui permet à une équipe de les utiliser comme critères de validation du pipeline. L’autorisation au niveau de l’objet sort du cadre descriptible par une règle et nécessite donc un autre outil.

Comment détecter des failles sans motif identifiable ?

Pour détecter des failles sans motif identifiable, vous pouvez raisonner à partir d’un modèle de l’application plutôt que du seul fichier sous vos yeux.

Pour détecter le bug de la facture, il faut connaître quatre faits : ce qui appelle ce point de terminaison, à quoi appartient l’objet récupéré, quels utilisateurs y ont droit et où se situe la frontière de confiance entre les tenants. On peut retrouver ces faits dans le codebase, le schéma et l’environnement de production, mais il faut les assembler sous une forme exploitable par une analyse. Snyk appelle ce modèle assemblé le graphe de contexte applicatif : architecture, flux de données, classifications des données, frontières de confiance et réalité de la production, réunis une fois puis mis à jour au fil des modifications du code. Une fois ce modèle créé, l’absence de vérification de propriété devient visible : l’analyse peut comparer ce que le point de terminaison applique aux exigences des règles propres à l’application.

Trois conditions rendent le résultat fiable.

1. Le raisonnement doit s’appuyer sur ce modèle. Sans lui, un raisonnement de pointe produit des résultats plausibles sur un codebase qu’il a en partie imaginé et consomme des jetons à analyser à l’aveugle.

2. Les résultats doivent être confirmés par un mécanisme qui ne les a pas produits. On ne peut pas faire confiance à un agent qui découvre une vulnérabilité pour valider sa propre correction, et un système qui évalue ses propres résultats reconduit tout ce que son analyse a manqué.

3. La correction doit être prouvée, pas seulement proposée. La correction d’une ligne doit être validée au regard des règles de l’application et démontrée efficace à mesure que le code évolue. Un résultat qui ne débouche jamais sur une correction intégrée laisse le point de terminaison aussi exposé qu’avant.

S’appuyer sur le raisonnement appliqué à l’application assemblée, tout en exécutant des moteurs déterministes en parallèle, est l’orientation que prend Snyk avec Evo Agentic AppSec, présenté en avant-première en août. Les tests à l’exécution confirment ensuite ce qu’un attaquant peut atteindre : c’est là qu’intervient aujourd’hui Evo Continuous Offensive Security.

Que peut faire votre équipe dès maintenant ?

Cinq étapes, qui ne nécessitent aucun nouvel outil pour commencer.

1. Répertoriez les points de terminaison qui acceptent un identifiant d’objet issu de la requête. Chaque route qui récupère un ID, un nom de fichier ou une clé depuis une URL ou un corps de requête est concernée. Cette liste est généralement plus courte que prévu par les équipes, et plus longue qu’elles ne l’espèrent.

2. Consignez les règles de propriété. Pour chaque type de ressource, indiquez à quoi elle appartient et qui peut la lire ou la modifier. Les failles d’autorisation passent la revue parce que ces informations n’ont jamais été consignées dans un endroit accessible aux personnes chargées de la revue ou de l’analyse.

3. Ajoutez l’autorisation comme point de contrôle explicite lors de la revue des pull requests rédigées par des agents. Pas une consigne générale demandant d’examiner soigneusement le code, mais une question précise : ce point de terminaison vérifie-t-il que l’appelant a droit à l’objet, et à l’aide de quel champ ?

4. Ajoutez un test inter-tenant pour chaque type de ressource. Les recommandations de prévention d’OWASP sont claires : les développeurs et le personnel QA doivent inclure des contrôles d’accès fonctionnels dans leurs tests unitaires et d’intégration. Un test par ressource, qui vérifie qu’une session valide d’un tenant reçoit un 404 lorsqu’elle demande l’objet d’un autre tenant, transforme la règle consignée à l’étape deux en une règle effectivement appliquée.

5. Effectuez régulièrement une analyse approfondie de l’ensemble du codebase. Le point de contrôle se divise en trois : en temps réel dans la boucle interne de l’agent, des analyses déterministes rapides à chaque modification dans la CI, et une analyse contextuelle approfondie de l’ensemble du codebase. C’est cette troisième étape qui fait ressortir les failles d’autorisation au niveau de l’objet.

Lesquels de vos points de terminaison échoueraient aujourd’hui à ce test inter-tenant ? Commencez par l’inventaire de la première étape. Pour découvrir l’approche de Snyk en matière de sécurité des applications agentiques, lisez Un premier aperçu d’Evo Agentic AppSec.