Analyse de la bibliothèque OAuth écrite par l’IA de Cloudflare

• Cloudflare a développé une nouvelle bibliothèque OAuth en s’appuyant sur le LLM Claude d’Anthropic, et a également publié les prompts utilisés
• La structure du code de la bibliothèque est propre, mais présente de nombreuses limites du point de vue des tests et de la validation de sécurité
• Des choix non standard ou risqués ont été relevés dans CORS et dans l’implémentation de certaines parties des spécifications d’authentification
• L’implémentation cryptographique a des points forts, mais révèle aussi des bugs de sécurité majeurs et des incompréhensions du protocole
• Le codage automatique basé sur un LLM peut aider, mais pour une sécurité de niveau production, un examen minutieux par des experts reste indispensable

---

Vue d’ensemble de la bibliothèque OAuth de Cloudflare

• Cloudflare a rédigé en grande partie de manière automatisée une bibliothèque de provider OAuth à l’aide du LLM Claude d’Anthropic
• La sortie de Claude a fait l’objet d’un examen de sécurité et de conformité aux standards par des ingénieurs expérimentés de Cloudflare, et l’historique des commits montre de façon transparente le processus d’interaction avec l’IA
• Après l’implémentation initiale, la qualité a été améliorée via de nouveaux prompts adressés à Claude et un examen de ses résultats
• Il est explicitement précisé qu’il ne faut pas s’appuyer uniquement sur l’IA, et que la vérification croisée avec les RFC ainsi que la revue par des experts clés sont essentielles

Première impression de l’expert et analyse du code

• Comme souvent avec le code produit par un LLM, le code est concentré dans un seul fichier, mais la structure reste cohérente et les commentaires inutiles sont relativement rares
• Des tests fonctionnels existent, mais ils n’atteignent pas le niveau requis pour un service d’authentification critique comme OAuth
  • On y voit des vérifications manquantes sur des exigences obligatoires (MUST/MUST NOT) ainsi qu’une validation des paramètres insuffisante

Inquiétudes liées à la sécurité et explications du traducteur

1. Problème de politique CORS (« YOLO CORS »)

• Une configuration des en-têtes CORS autorisant presque toutes les origines a été repérée, ce qui désactive de fait la politique de même origine
• Ce point a été décidé directement par un humain, et non par le LLM
• La fonctionnalité credentials n’étant pas activée, le risque de menace critique pour la sécurité du navigateur est plus faible, mais la raison et l’objectif de ce choix restent insuffisamment clairs

2. Absence de certains en-têtes de sécurité standard

• Les réponses HTTP ne définissent pas certains en-têtes de sécurité essentiels comme X-Content-Type-Options: nosniff et HTTP Strict Transport Security
• Même si, pour une API JSON, la nécessité de certains en-têtes peut sembler moindre, leur adoption reste importante pour prévenir des vulnérabilités côté client ou navigateur

3. Signes d’une maîtrise incomplète du standard OAuth

• Pour prendre en charge les clients publics, l’implémentation utilise le flux implicit grant, pourtant abandonné dans OAuth 2.1
  • En pratique, cette fonctionnalité pourrait être remplacée de manière suffisante par PKCE ou un assouplissement de CORS
  • Il semble que Claude ait recommandé implicit grant, mais l’étape réelle d’émission du token ne le valide pas correctement
• Gestion incomplète de Basic Auth : OAuth exige un schéma particulier d’encodage d’URL, ici omis
  • Cela crée un bug de sécurité secondaire possible si le secret client contient un deux-points
  • Cela dit, la bibliothèque génère elle-même les identifiants et secrets client, ce qui permet de contrôler leur format

4. Problèmes de sécurité dans le code de génération des identifiants de token

• La méthode de génération de chaînes aléatoires pour les identifiants de token présente un biais statistique
  • Cela peut réduire l’entropie et faciliter certaines attaques, même si la menace concrète reste limitée
• Contrairement à l’affirmation selon laquelle chaque ligne de code aurait été revue par des experts, le bug est resté présent dans le commit initial
  • L’historique montre notamment qu’un développeur a poussé directement 21 commits sur la branche principale dès le premier jour, ce qui suggère un manque de revue systématique

Fonctionnalités cryptographiques et exemple d’interaction avec le LLM

• La conception du chiffrement du stockage des tokens a été pilotée par un humain, l’implémentation étant assistée par Claude
• L’approche consiste à chiffrer les propriétés de chaque token et à encapsuler une clé symétrique propre à chaque token
• Lorsque Claude a proposé un schéma incorrect en cours de route, l’ingénieur a clarifié explicitement l’intention et l’objectif de sécurité afin de le corriger
  • Exemple : après avoir signalé la vulnérabilité qu’impliquerait l’usage d’un hachage SHA-256 comme clé d’encapsulation, la conception a été modifiée vers une approche basée sur HMAC
  • Face à la suggestion d’utiliser PBKDF2, son inefficacité en termes de performance a été soulignée, puis l’implémentation a été ajustée avec une clé HMAC de 32 octets
• Ce processus montre bien qu’un haut niveau de connaissance du domaine est nécessaire lorsqu’on travaille avec une IA
  • Un non-spécialiste pourrait ne même pas remarquer certains défauts critiques

Bilan et enseignements

• Même pour une première version, le niveau global est correct, mais le risque est trop élevé pour l’appliquer directement à un service en production
• Le développement d’un provider OAuth exige par nature une validation de sécurité et de fonctionnalité extrêmement exigeante
  • Dans les grandes entreprises, il est courant d’avoir des centaines de milliers de tests automatisés et des contrôles de sécurité multicouches
  • Ce n’est pas un domaine où l’on peut appliquer « facilement » le codage automatique basé sur des LLM
• L’historique des commits du projet montre de manière intéressante jusqu’où un LLM peut jouer un rôle d’assistance
  • Certains défauts sont toutefois des erreurs que les LLM comme les humains commettent fréquemment, et qu’on retrouve aussi dans des réponses de Stack Overflow ou d’autres ressources communautaires
  • Dans les zones de code où la rigueur et l’attention au détail sont cruciales, IA et humains ont tous deux besoin d’une vigilance extrême
• Pour utiliser un LLM pour revoir du code ou faire confiance à ses résultats, une expérience directe d’implémentation et une réflexion de type System 2 sont indispensables
  • On peut confier sans problème des tâches simples ou non critiques à un LLM, mais pour les systèmes majeurs liés à l’authentification ou à la sécurité, une conception et une implémentation pilotées par des experts restent préférables

[xguru]

Cloudflare publie comment il a construit OAuth avec Claude et rend publics tous les prompts

[GN⁺]

Commentaires sur Hacker News

• Ce cas montre très directement qu’il faut beaucoup de connaissances métier pour interagir avec un LLM. Par exemple, un développeur ordinaire pourrait ne pas remarquer le « défaut critique » inventé par Claude en cours de route. Le fait de trouver étrange le passage à PBKDF2 vient aussi d’une expertise du domaine. Ma conclusion est que, pour utiliser efficacement un LLM, il faut un bon relecteur et un « leader ». Si l’on en sait moins que le LLM sur le sujet, il faut impérativement soit que l’enjeu soit faible, soit disposer de suffisamment de temps pour tout vérifier dans ses sorties

  • Dans ce nouvel environnement, je me demande d’où viendront les experts métier à l’avenir. Au fond, qui pourra encore acquérir une compréhension aussi profonde ?

  • Chaque fois que j’entends dire « on n’utilise les LLM que dans les domaines qu’on ne connaît pas, un expert code lui-même », ça me semble étrange. En réalité, plus on est expert, mieux on peut relire la sortie du LLM, et plus on sait décrire ce qu’on veut d’une manière proche de celle d’un expert du domaine, meilleur est le résultat. D’une certaine façon, c’est évident, puisque les LLM sont des moteurs de texte générés statistiquement

  • Les LLM ont tendance à ajouter trop facilement des valeurs par défaut, des traitements d’exception et toutes sortes de contournements. On obtient donc facilement du code qui semble fonctionner, mais qui a en réalité des problèmes ou va bientôt échouer. J’ai essayé d’insister plusieurs fois sur ce point dans mon CLAUDE.md, mais ce type de résultat revient quand même souvent

  • J’ai confié à un LLM la majeure partie de mes déploiements k8s. Il produit vite quelque chose qui marche, mais il fallait sans cesse lui rappeler d’utiliser des secrets et de ne pas committer des identifiants en clair. Ce genre d’erreur est vraiment dangereux. Les tutoriels pédagogiques omettent souvent la sécurité pour se concentrer sur les bases, et comme il y a énormément d’exemples de ce genre dans les données d’entraînement des LLM, j’imagine que c’est pour cela qu’ils produisent ce type de sortie

  • Avec le temps, j’espère que les outils de code IA pourront eux-mêmes rechercher les connaissances métier. Certains outils d’« AI research » déjà sortis sont très bons pour ça, mais ils ne sont pas encore vraiment intégrés aux outils de développement. La recherche pourrait s’appuyer non seulement sur l’Internet public, mais aussi sur les documents internes de l’entreprise. Cela dit, une partie du savoir n’existe que dans la tête des gens, donc l’utilisateur devra quand même le transmettre directement

• J’ai récemment écrit un consumer Kafka avec l’aide de l’IA pour faire une migration de données. C’était le cas d’usage idéal : un projet court, à repartir de zéro, dans une langue (Go) que je connais bien mais que je n’avais pas utilisée depuis longtemps. C’est là que l’IA m’a été la plus utile. Toutes les données arrivaient dans un seul topic, donc j’ai mis en place un traitement parallèle assez complexe pour tenir les performances. Globalement, j’ai eu l’impression d’aller environ 2 fois plus vite grâce à l’IA. Le fait de pouvoir lui demander directement des points de syntaxe Go que j’oubliais parfois, au lieu de chercher, m’a particulièrement aidé. Mais il y avait au moins 4 bugs potentiels cachés dedans, sans compter beaucoup d’autres bugs évidents. Si je n’avais pas été familier avec Kafka ou le multithreading, j’aurais peut-être mis ça directement en production. Sur les projets larges ou de longue durée, le gain tourne plutôt autour de 10 à 20 %. Avec les modèles récents, c’est la tendance actuelle. Dans l’ensemble, cela ressemble au gain de productivité qu’on avait obtenu en passant à des langages avec gestion mémoire. On est loin du fantasme où des PM remplaceraient les développeurs, du moins au vu du rythme des trois dernières années. En revanche, ma vraie inquiétude, c’est qu’un développeur de niveau intermédiaire mais très productif puisse devenir 10 fois plus efficace avec l’IA tout en étant incapable de repérer ou de traiter des bugs subtils, ce qui le rendrait plus dangereux. Les ingénieurs senior/staff risquent de ne pas pouvoir absorber l’explosion des revues. Et je crains aussi que le parcours qui fait passer de junior à senior devienne plus fragile. Les programmeurs qui font déjà du copier-coller sont déjà un problème, et l’IA ne fait que renforcer ce schéma. Le marché finira peut-être par régler ça, mais il faudra peut-être des décennies, et c’est inquiétant

  • Les bugs produits par l’IA sont vraiment insidieux. J’ai moi aussi déjà laissé partir en production un bug subtil dans du code multithread généré par l’IA. Même avec revue et tests, on n’atteint pas le même niveau de concentration que lorsqu’on a tout écrit soi-même. Pour l’instant, j’ai le sentiment qu’il faut traiter le code généré par l’IA en vérifiant à l’avance les bugs habituels, et en le limitant à des zones où l’impact d’une erreur critique est faible

  • Moi aussi, sur les « tâches importantes », je ressens plutôt un gain de 10 à 20 %. C’est un vrai changement, mais ça ne transforme pas la nature fondamentale du développement logiciel. Au fond, cela ne fait que confirmer la thèse de Brooks dans No Silver Bullet

  • Je suis également d’accord avec l’idée du « niveau intermédiaire suralimenté ». Dans le conseil en particulier, les vétérans sont souvent considérés comme peu rentables. À une époque, j’étais moi-même plutôt du genre à aller vite, puis j’ai dû plus tard me battre pour expliquer à des PM non spécialistes les faiblesses de solutions de court terme. Les grandes entreprises tech détecteront sans doute vite ce genre de problèmes, mais dans la réalité, le code qui manipule des données financières ou médicales est souvent écrit par des contractuels bon marché sur de courtes missions. C’était déjà un problème avant l’arrivée des LLM. Aujourd’hui, cela doit être une époque bien plus difficile pour les développeurs sensibles aux enjeux de sécurité

  • Tu dis avoir trouvé des bugs subtils dans le code généré ; je me demande ce que donnerait leur détection automatique avec du code de test lui aussi généré par l’IA. Bien sûr, le code de test peut lui-même contenir des bugs, mais j’imagine bien un futur où l’on se concentrerait surtout sur la revue des résultats de tests plutôt que du code généré lui-même

  • Tu parles de traitement parallèle complexe, mais est-ce que ce n’est pas justement un problème qui pourrait être résolu avec des partitions et des consumer groups ?

• Quand je vois des gens faire totalement confiance aux LLM, s’y accrocher sans recul comme s’ils tombaient d’une falaise, ça me crispe. S’appuyer entièrement sur une boîte noire pour produire et valider le travail est dangereux. En plus, cela repose sur une infrastructure qui consomme une quantité d’énergie énorme, et sert aussi parfois d’excuse pour remplacer des gens. Franchement, j’ai du mal à croire que cet environnement rende la vie 10 fois meilleure

• Quand on compare le fait de développer soi-même avec la validation d’un résultat produit par quelqu’un d’autre — en particulier du code généré par un LLM — les humains ont souvent tendance à se laisser tromper par une apparence plausible et à accepter les problèmes de manière moins critique. L’« allure » du code influence énormément la capacité à trouver des bugs. Pour vérifier cela, on pourrait volontairement injecter des bugs dans du code et voir si les relecteurs les repèrent. Quand on implémente quelque chose soi-même, on réfléchit bien plus lentement, de façon bien plus minutieuse, et on prête plus attention aux détails, ce qui permet aussi de découvrir des bugs inattendus. C’est pour cela qu’on recommande souvent, dans une optique d’apprentissage, d’écrire soi-même une version « jouet » d’un outil. Cela touche à la manière dont la cognition humaine fonctionne

  • La capacité à repérer des bugs subtils dans un code apparemment propre vient d’une forme de cynisme et de suspicion acquise à force de faire des revues. À force d’y consacrer beaucoup de temps, j’en suis arrivé à toujours supposer des problèmes potentiels dans n’importe quel code. Mon propre code aurait peut-être eu moins de bugs, mais je ne peux pas l’affirmer : j’ai moi aussi souvent commis des erreurs stupides. En réalité, il y a peu de chances que j’aurais écrit moi-même cette bibliothèque, faute de temps ; ce genre de travail aurait plutôt été confié à un ingénieur junior. Une chose dont je suis sûr, c’est que le fait qu’un humain écrive le code n’élimine pas les bugs. D’ailleurs, beaucoup des bugs produits par Claude sont d’un type tout à fait classique qu’un humain pourrait très bien introduire lui aussi. En revanche, à ce stade, je ne pense pas que les développeurs seront remplacés chez Cloudflare à cause des LLM. Le recrutement dépend davantage du budget que du volume de travail. Si les LLM augmentent la productivité, cela peut accroître le chiffre d’affaires et conduire à embaucher davantage. (Bien sûr, ce n’est pas une position officielle de l’entreprise, seulement mon opinion personnelle)

• L’article dit qu’il n’y a pas trop de commentaires inutiles, mais dans le code réel on trouve des choses comme // Get the Origin header from the request, qui n’apportent rien

  • Ce genre de commentaire trahit l’usage d’un LLM ; je les supprime toujours parce qu’ils ne servent à rien

  • Pour un humain, ces commentaires n’ont aucune utilité, mais du point de vue d’un LLM, le fait que la fonction du code soit aussi décrite en langage naturel juste en dessous pourrait jouer un rôle de pierre de Rosette et l’aider à mieux comprendre. Cela coûte plus de tokens, bien sûr, mais j’aimerais bien vérifier si les LLM modifient réellement mieux un code excessivement commenté

  • Partage d’expérience : Claude a vraiment tendance à écrire très souvent ce genre de commentaires inutiles et redondants

• Ce que j’aimerais proposer, c’est de geler une branche du code, puis d’utiliser des IA dans une sorte de combat où un camp essaie d’introduire et de dissimuler des vulnérabilités, tandis que l’autre essaie de les trouver et de les corriger. En d’autres termes, appliquer à l’évolution du développement logiciel ce qui s’est passé avec les échecs

• Je suis justement l’auteur de cette bibliothèque — ou plus précisément, l’auteur du prompt. Je ne suis pas un expert OAuth du niveau de Neil, mais j’ai quand même une certaine expertise, et j’étais vraiment ravi qu’il fasse la revue du code. Il y a eu un malentendu à propos de « YOLO CORS » : ce n’est pas une erreur de débutant faite au hasard. Ces réglages CORS ont été réfléchis et intentionnels. Je ne désactive CORS que pour les endpoints de l’API OAuth (échange de tokens, enregistrement de client) et pour les endpoints d’API qui nécessitent un OAuth bearer token. Ces endpoints ne sont pas authentifiés par des identifiants de navigateur (cookies, etc.), donc selon moi CORS n’y protège en réalité rien. L’essence de CORS, c’est une barrière de sécurité qui empêche l’ajout automatique de credentials, alors qu’un bearer token doit être ajouté explicitement par le client, ce qui le rend sûr même en cross-origin. D’ailleurs, j’ai déjà débattu par le passé avec des auteurs de la spec CORS en soutenant que l’usage de bearer tokens plutôt que de credentials navigateur était la vraie approche sûre. Concernant la critique sur l’inefficacité de la génération des token IDs, je ne pense pas que ce soit « critique ». Ce n’est pas un problème de sécurité en soi, et l’algorithme pourra être modifié librement plus tard. Le fait que 21 commits d’une seule personne apparaissent sur main le même jour vient d’une réécriture de l’historique git, qui a faussé les dates affichées sur GitHub. Merci aussi pour les compliments sur l’implémentation crypto. Ce n’est pas l’IA qui l’a produite : c’est le résultat de mes consignes de conception explicites

  • Tu dis « désactiver les en-têtes CORS sur l’API OAuth », mais en réalité il s’agit de configurer les en-têtes CORS de manière à désactiver les règles CORS. Le contexte permet de comprendre, mais la formulation peut prêter à confusion

  • Je me demande si Cloudflare prévoit d’utiliser réellement cette bibliothèque en production

• Quand on voit que beaucoup de réponses populaires sur Stack Overflow contiennent exactement les mêmes erreurs, et que Claude a probablement appris à partir de cela, c’est inquiétant. Plus encore que les failles de sécurité ou les erreurs elles-mêmes, ce qui me fait peur, c’est que la connaissance collective se fige dans les réponses populaires de l’Internet d’avant les LLM

  • Cela m’inquiète aussi. Si certains services annonçaient publiquement qu’ils n’utilisent pas de LLM pour écrire leur code, cela constituerait pour moi un vrai facteur de confiance

• Voir que ForgeRock a eu des centaines de failles de sécurité dans son implémentation d’OAuth, malgré des centaines de milliers de tests automatisés, de la modélisation de menaces, du SAST/DAST de très haut niveau, des revues d’experts, etc., rappelle à quel point OAuth est vraiment difficile. Certains parlent même d’implémentations en « feu de décharge ». Cela dit, je n’ai moi-même jamais lu la spec ni implémenté OAuth

  • Chaque fois que j’ai été impliqué dans une implémentation OAuth, j’ai toujours trouvé ça horriblement complexe

  • OAuth est vraiment pénible, et il y a énormément de cas de niche

  • En réalité, du code nouvellement écrit contient toujours des bugs. Plus c’est complexe, plus c’est vrai. C’est pour cela que les entreprises essaient d’utiliser du code et des outils battle tested, déjà éprouvés en conditions réelles. Blague à part, la manière dont Anthropic utilise concrètement son IA générative sur son propre code est intéressante. Je me demande s’ils l’appliqueront aussi à l’API d’authentification MCP

  • Des « centaines de milliers de tests », ça ressemble forcément à une inflation quantitative, ou alors carrément à des tests générés par LLM. Je me demande aussi qui maintient réellement tout ça

• Je me demande si la tendance consistant à committer ses prompts dans git va se généraliser, ou si c’est juste pour l’effet vitrine

  • Si j’ai committé le prompt, c’est parce qu’il était extrêmement instructif de voir directement quel résultat le LLM produisait à partir de ce prompt. Je pensais que d’autres trouveraient cela intéressant aussi, et ça a effectivement été le cas. D’ailleurs, je ne sais pas non plus particulièrement « bien » écrire des prompts ; je l’ai simplement formulé naturellement, comme je l’aurais fait pour un humain, et j’ai eu l’impression que cela fonctionnait bien