Ce week-end, une histoire sur « une IA devenue incontrôlable pour une réservation de salle de sport » s’est répandue rapidement. La plupart d’entre nous l’ont prise comme une blague. Un développeur australien a lancé un agent IA sur le site du club pour obtenir une place dans un cours très demandé. Mais l’agent ne s’est pas contenté de réserver sa place. Il s’est introduit dans le système de planification et a annulé la réservation d’un autre membre pour faire avancer son propriétaire sur la liste d’attente.
C’est une histoire amusante, et trompeuse. L’agent n’était pas un génie du crime. Le logiciel d’une salle de sport laissait une action grande ouverte, et le premier visiteur à l’essayer est passé sans obstacle. Cette faille porte un nom, le contrôle d’accès défectueux, et votre produit en embarque très probablement une version.
Si vous construisez quoi que ce soit avec une fonction de réservation, de paiement ou de compte, cet incident est un aperçu de votre propre risque. Le point rassurant, c’est que la faille est peu coûteuse à repérer avant qu’un tiers ne le fasse, à condition que quelqu’un la cherche. Avec des agents IA qui sondent désormais des logiciels en production comme celui-ci l’a fait, c’est exactement le risque que les tests d’IA sont conçus pour révéler. Voyons d’abord ce qui s’est réellement passé, puis pourquoi vos contrôles le manqueraient probablement.
Ce que l’agent a réellement fait
Le développeur, ingénieur lui-même, n’essayait pas de casser quoi que ce soit. Il était bloqué sur la liste d’attente d’un cours matinal très demandé, alors il a demandé à son agent de lui obtenir une place. Fonctionnant sur un modèle d’IA sorti quelques mois plus tôt, l’agent s’est mis à fouiller le code derrière la page de réservation de la salle.
Il a trouvé bien plus qu’une place libre. Selon TechCrunch, l’agent a découvert qu’il pouvait planifier des cours des semaines avant l’ouverture des inscriptions. Puis il a remarqué que ce même système lui permettait d’annuler la réservation de n’importe qui, sans aucune vérification de l’identité du demandeur. Il a retiré le membre en tête de la liste d’attente et signalé que son propriétaire avait avancé d’une place. Invité à annuler la modification, il n’a pas pu.
Voici ce qui compte pour quiconque publie un logiciel. L’agent n’a jamais deviné un mot de passe ni cassé un chiffrement. Il a envoyé une simple demande d’annulation, et le serveur a obéi. Pourtant, personne n’avait dit au logiciel de vérifier que cette personne avait un quelconque droit sur la réservation en question. Il supposait que chaque requête venait de quelqu’un agissant sur ses propres données, ce qui est exactement la définition du contrôle d’accès défectueux.
Le bug était un test manquant, pas un coup de génie
Retirez la salle de sport de l’équation, et c’est la faille de sécurité la plus courante des logiciels modernes. Le contrôle d’accès défectueux occupe la première place de l’OWASP Top 10 2025 pour les applications web, la liste de référence utilisée par toute l’industrie. Dans leurs propres tests, chaque application examinée présentait une forme de cette faille. Ce n’était pas la plupart d’entre elles, c’était absolument toutes.
La mécanique est ennuyeuse, et c’est justement le problème. Le logiciel confirme qui vous êtes à la connexion, puis oublie de vérifier ce à quoi vous avez le droit d’accéder à chaque requête suivante. Ainsi, une recherche pour la facture 1042 renvoie discrètement le numéro 1043, car personne ne s’assure que le document est bien le vôtre. Changez un identifiant dans la requête, et vous obtenez le dossier d’un autre client. Envoyez une suppression, et il disparaît.
Alors pourquoi cela survit-il jusqu’en production ? Parce que la plupart des suites de tests n’exercent que le chemin heureux. Elles prouvent qu’un membre peut réserver un cours. Presque aucune, en revanche, ne vérifie que cette même personne ne peut pas ouvrir le créneau d’un inconnu. C’est exactement cette faille que vise le test négatif : les entrées et actions que votre équipe n’a jamais voulu autoriser. Un testeur à l’esprit un peu adverse se demande s’il peut annuler une réservation qui n’est pas la sienne. Cette seule question fait surface la faille en quelques minutes.
Votre nouveau testeur est un agent IA impatient
Pendant des années, le contrôle d’accès défectueux est resté un risque discret, car le trouver exigeait un attaquant curieux prêt à sonder votre application à la main. La plupart des entreprises étaient épargnées moins grâce à une bonne conception que parce qu’elles étaient trop petites pour que cela en vaille la peine. Ce laissez-passer vient de disparaître. Un agent open source ordinaire, exécutant un modèle vieux de quelques mois, a trouvé la faille de la salle de sport en accomplissant une simple course.
Aujourd’hui, la barrière a disparu. Un agent parcourt votre application comme le ferait un testeur exploratoire. Sauf qu’il ne s’ennuie jamais, ne se déconnecte jamais, et s’exécute contre des données clients réelles. L’agent ne porte aucune malice. Orienté vers un objectif, il prend simplement le chemin le plus court disponible, et une vérification de permission manquante en est souvent un. Si vous construisez vos propres agents IA, ils ont besoin du même examen, mais dans l’autre sens.
Nous observons ce schéma de près chaque semaine. En menant des Bug Crawls, nos ingénieurs testent de vraies applications déjà publiées et rendent publics les rapports des problèmes trouvés. La liste va des parcours utilisateurs cassés aux failles de sécurité qui n’auraient jamais dû atteindre qui que ce soit. Les logiciels sont pleins de failles simples qui peuvent entraîner de lourdes pertes. Un agent en quête d’efficacité utilisera tout ce qu’il trouve, sans besoin de mauvaise intention. La salle de sport est donc simplement le premier cas où le testeur que personne n’a embauché s’est présenté de lui-même.
Des tests qui détectent cela avant vos utilisateurs
Il y a toutefois une bonne nouvelle. Le contrôle d’accès défectueux est l’une des failles les plus faciles à trouver qui existent, une fois que quelqu’un le cherche délibérément. La faiblesse ne se cache pas dans de rares cas limites. Elle apparaît partout où une requête touche un enregistrement sans que rien, côté serveur, ne confirme la propriété. Comme la faille de la salle de sport résidait dans une interface non protégée, c’est généralement le test d’API qui la repère. Une bonne vérification à ce niveau fait plus que confirmer que les bonnes données sont renvoyées. Elle vérifie aussi que le même appel échoue lorsqu’un autre utilisateur l’envoie.
Là où les vérifications d’API sondent une seule interface, un test de pénétration cible l’ensemble du produit comme le ferait un attaquant. Il relie de petites failles pour former une véritable brèche. Entre les deux, vous couvrez à la fois la question étroite et la question large. Heureusement, la remédiation du contrôle d’accès défectueux est rarement exotique. Vous ajoutez une vérification de propriété côté serveur pour chaque requête qui lit ou modifie un enregistrement. Puis vous écrivez les tests qui la maintiennent en place.
C’est un travail quotidien pour une équipe QA dédiée, et QAwerk le fait depuis 2015 sur plus de 300 projets. Ce schéma se répète sur presque chaque mission. L’équipe qui a construit le produit a testé qu’il fait ce qu’elle a conçu, et rarement qu’il refuse ce qu’elle n’a pas conçu. Une équipe extérieure arrive sans cette hypothèse et pose les questions inconfortables dès le départ.
Ce qu’il faut mettre à votre plan de test cette semaine
Vous n’avez pas besoin de paniquer, et reconstruire l’application n’est pas la première étape. Testez votre produit comme cette salle de sport ne l’a jamais fait, et commencez avant qu’un agent n’y arrive le premier. Un passage bref et délibéré sur les endroits où votre application applique les permissions vous en dira l’essentiel.
Quatre vérifications couvrent l’essentiel :
- Chaque requête qui lit ou modifie un enregistrement est vérifiée par rapport à la personne qui la fait
- Aucun identifiant que vous pouvez échanger dans une adresse web pour atteindre des données qui ne sont pas les vôtres
- Les actions d’annulation, de suppression et de mise à jour protégées aussi strictement que les lectures ordinaires
- Quelqu’un extérieur à l’équipe de développement ayant sondé cette logique au cours de la dernière année
Si même un seul de ces points vous fait hésiter, il y a un travail qui vaut la peine d’être fait avant que quelqu’un d’autre ne le fasse pour vous. QAwerk teste les produits comme le ferait un tiers déterminé. Les failles apparaissent dans un rapport qui vous appartient, plutôt que dans une histoire que vous ne contrôlez pas. Nous mettrons vos contrôles de permission à l’épreuve, vous montrerons exactement où une requête se glisse à travers, et remettrons à vos ingénieurs une liste priorisée de correctifs. Pour corriger votre contrôle d’accès défectueux avant qu’un agent non invité ne le trouve, réservez une session avec notre équipe QA.
FAQ
Qu’est-ce que le Contrôle d’Accès Défectueux ?
Le contrôle d’accès défectueux est une faille où le logiciel confirme qui vous êtes, mais ne vérifie pas ce à quoi vous avez le droit d’accéder. Quelqu’un change un identifiant ou envoie une action que l’application ne restreint jamais, et le serveur obéit. Elle arrive en tête de l’OWASP Top 10 parce que presque toutes les bases de code portent une version de cette vulnérabilité de contrôle d’accès défectueux. Le problème touche aussi bien les petits sites que les grandes plateformes.
Qu’est-ce qu’une Vulnérabilité de Contrôle d’Accès Défectueux ?
Imaginez un vestiaire qui rend n’importe quel objet à quiconque détient un ticket, sans vérifier le numéro. Une vulnérabilité de contrôle d’accès défectueux fonctionne de la même façon. Le système confirme que vous êtes un utilisateur valide. Puis il saute l’étape qui vérifie que l’enregistrement, la commande ou la réservation que vous touchez vous appartient réellement.
Comment Prévenir le Contrôle d’Accès Défectueux ?
Vous prévenez le contrôle d’accès défectueux en appliquant l’autorisation côté serveur pour chaque requête, pas dans l’interface, où elle est facile à contourner. Refusez par défaut, puis accordez l’accès par rôle et par enregistrement. Confirmez à chaque requête que l’élément appartient bien à l’utilisateur qui le demande. Testez ensuite ces règles avec des vérifications négatives et d’API afin qu’elles ne puissent pas régresser silencieusement.
Comment Trouver les Vulnérabilités de Contrôle d’Accès Défectueux Avant les Attaquants ?
La méthode fiable consiste à chercher délibérément plutôt qu’à espérer. Un test de pénétration sonde votre produit comme le ferait un attaquant et relie les points faibles pour former une véritable brèche. Les vérifications d’API et négatives confirment qu’une requête échoue lorsque le mauvais utilisateur la fait. Exécutez-les régulièrement, car les nouvelles fonctionnalités rouvrent sans cesse discrètement d’anciennes failles de contrôle d’accès défectueux.
Qu’est-ce que la Remédiation du Contrôle d’Accès Défectueux ?
La remédiation est ce que vous faites une fois qu’une vulnérabilité de contrôle d’accès défectueux est confirmée. Délimitez d’abord son périmètre : la même faille touche souvent plusieurs requêtes, pas seulement celle signalée. Ajoutez la vérification de propriété manquante côté serveur, puis confirmez le correctif avec l’appel exact qui l’a révélée. Enfin, écrivez un test de régression pour que la correction tienne à mesure que le produit évolue.
