Une salle de sport australienne, un cours complet, une file d’attente. Sur le site de réservation, OpenClaw (un assistant personnel open source à qui l’on confie des tâches dans le navigateur) cherche le raccourci le plus direct pour faire remonter son utilisateur : effacer la réservation de la personne qui le précède. Et ça passe.
Le compte rendu que l’agent en fait, publié tel quel, mérite d’être lu lentement : « L’API n’a aucun contrôle d’autorisation sur l’annulation des réservations des autres. J’ai testé avec la personne en position 1 de la liste d’attente, et ça a marché. Vous êtes donc déjà passé de la 4e à la 3e place. » Ni excuse, ni étonnement : l’agent rend compte, comme d’une fonctionnalité.
La question naïve, celle que se pose n’importe quel utilisateur devant cette scène, est la bonne : comment un logiciel peut-il supprimer quelque chose qui ne lui appartient pas ?
Authentifier n’est pas autoriser
Une API répond à deux questions distinctes. La première : qui êtes-vous ? C’est l’authentification, gérée par un login, un token, un cookie de session. Sur ce point, la plupart des applications tiennent la route : sans compte valide, vous n’entrez pas.
La seconde question est d’une autre nature : avez-vous le droit de faire cette action sur cet objet précis ? C’est l’autorisation, et elle se joue ligne par ligne, objet par objet. Quand l’application reçoit une demande de suppression de la réservation numéro 8421, quelqu’un doit vérifier que cette réservation appartient bien au compte qui la demande. Si personne ne pose la question, l’endpoint (l’adresse de l’API qui traite la demande) fait exactement ce qu’on lui demande : il supprime.
L’image la plus juste est celle de la salle elle-même. Un portier contrôle votre badge à l’entrée, sérieusement, à chaque passage. Puis vous arrivez dans un vestiaire où aucun casier n’a de cadenas. Vous êtes bien vous, personne n’en doute, et c’est précisément pour ça que vous pouvez ouvrir celui du voisin. Le secteur a un nom pour cette famille de failles : la Broken Object Level Authorization, ou BOLA, littéralement l’autorisation cassée au niveau de l’objet. Depuis des années, l’OWASP, la référence de la sécurité applicative, la classe au premier rang des vulnérabilités d’API. Elle n’a rien d’exotique ni de sophistiqué.
Le contrôle que personne n’a écrit
Cette faille de manuel réapparaît pourtant en 2026, à l’heure où une application de réservation s’écrit en un week-end avec un assistant. La raison tient à la façon dont un modèle produit du code.
Demandez une API de réservation : vous obtiendrez les routes, le schéma de données, les migrations, la validation des champs, le CRUD complet (créer, lire, modifier, supprimer). Tout cela est présent des millions de fois dans le corpus d’entraînement, tout cela est nommable, testable, visible à l’écran. Le modèle restitue fidèlement la surface de l’application.
Les règles d’autorisation, elles, n’apparaissent nulle part dans cette surface. Aucun framework ne les fournit : elles relèvent du métier, de ce principe qui veut qu’un adhérent gère ses créneaux et seulement les siens. Personne ne l’a écrit dans la consigne parce que cela va de soi, et un assistant ne réclame pas ce qu’on ne lui a pas dit de réclamer.
L’application qui en sort fonctionne parfaitement. Rien ne signale l’absence : le code compile, les tests passent au vert, la démonstration est convaincante, le linter (l’outil qui inspecte automatiquement le code) reste muet. Un contrôle manquant ne produit aucun symptôme. Et relire un diff, c’est lire ce qui a été écrit ; personne ne relit ce qui ne l’a pas été.
On teste le succès, jamais le refus
Cet angle mort se prolonge dans la batterie de tests, générée par le même assistant, dans le même mouvement. Ces tests vérifient qu’un adhérent peut réserver, qu’il peut annuler, que le compteur de places diminue. Le parcours nominal, du début à la fin.
Le test qui aurait sauvé le club australien est celui que presque personne n’écrit : l’utilisateur B tente d’annuler la réservation de l’utilisateur A, et le serveur doit répondre par un refus. Or un test qui exige une réponse négative suppose que la règle ait été formulée au préalable. On revient au même point de départ.
Quand explorer une API ne coûte plus rien
Le même outillage qui produit l’API sans garde-fou produit aussi l’explorateur qui trouve le trou, et il le fait sans compétence offensive particulière.
Un agent qui manipule un site ne se lasse pas. Il substitue des identifiants, rejoue une requête avec un autre numéro, observe le code de retour, recommence. Ce qui demandait hier un curieux motivé et quelques heures devient l’effet de bord d’une consigne banale, du type « fais-moi entrer dans ce cours ». Aucune intention malveillante n’est requise dans la boucle : l’agent ne se demande pas si annuler le créneau d’un inconnu est acceptable, il constate que le serveur l’autorise et poursuit son objectif.
Les assistants qui pilotent un navigateur chez les grands éditeurs posent au moins un cran d’arrêt côté client : Claude for Chrome réclame une validation humaine avant une action irréversible comme un achat, et l’agent de ChatGPT fait de même avant de valider une commande ou d’envoyer un message. Un assistant auto-hébergé lancé sans ce verrou n’a plus rien devant lui que le serveur, et c’est au serveur de dire non.
Écrire les refus avant les fonctionnalités
Combler ce vide ne demande pas de refonte, mais quatre réflexes au moment de commander le code :
- énoncer la règle de propriété dans la consigne, explicitement : quel rôle peut lire, modifier ou supprimer quel objet, et à quelle condition ;
- placer le contrôle dans la couche d’accès aux données plutôt que dans chaque contrôleur, pour qu’un nouvel endpoint ne puisse pas naître sans lui ;
- exiger des tests négatifs, un par action sensible, où la réponse attendue est un refus ;
- faire de la revue de code une chasse aux absences, avec une question posée à chaque route : qui vérifie ici que l’objet appartient au demandeur ?
La salle de sport australienne s’en remettra : son API se corrige en trois lignes. L’asymétrie, elle, ne se corrige pas. Écrire cette application a demandé quelques heures, la casser quelques minutes, et l’outil qui sert à la casser se diffuse aussi vite que celui qui a servi à l’écrire. Restent les milliers d’applications de réservation, de facturation ou de prise de rendez-vous nées de la même façon depuis un an, avec le même contrôle manquant. Désormais, n’importe quel adhérent équipé d’un agent peut le découvrir avant le développeur.
