cside copréside la sécurité antifraude du navigateur au W3C
La fraude se déroule de plus en plus dans la session du navigateur. Credential stuffing, prise de contrôle de compte, trafic publicitaire invalide, carding piloté par bots, scraping, faux engagements et abus automatisé dépendent tous de ce que la plateforme web autorise côté client.
La difficulté n'est pas de nommer les attaques. La difficulté est de les arrêter sans transformer le navigateur en couche de surveillance ni imposer des CAPTCHA répétés à chaque utilisateur légitime.
L'IA change rapidement le paysage de la fraude. Les attaquants peuvent générer des comportements de compte crédibles, automatiser des parcours de navigateur, coordonner des abus lents et distribués, et s'adapter plus vite que les règles statiques. Les défenseurs ont besoin de signaux de navigateur qui suivent ce rythme sans transformer chaque utilisateur en profil traçable.
C'est pourquoi Simon Wijckmans est désormais coprésident du W3C Anti-Fraud Community Group (AFCG), où il représente cside aux côtés de Sam Schlesinger de Google et de la communauté élargie qui travaille publiquement sur ce problème.
Ce que fait le W3C Anti-Fraud Community Group
L'AFCG existe pour identifier les lacunes de la plateforme web qui permettent la fraude et le trafic non désiré. Ses travaux portent sur des fonctionnalités et des APIs de navigateur capables de traiter ces scénarios tout en améliorant la sécurité, la vie privée et l'accessibilité des utilisateurs.
Le groupe est ouvert. Les éditeurs de navigateurs, les fournisseurs antifraude, les défenseurs de la vie privée, les développeurs web, les fournisseurs cloud et les opérateurs de services confrontés au trafic non désiré peuvent participer. Le travail technique se fait publiquement, principalement dans les dépôts AFCG de propositions et de cas d'usage.
Ce modèle public est important. Le travail antifraude échoue lorsqu'il devient une course privée entre pisteurs et attaquants. Les standards du navigateur exigent un niveau plus élevé : capacités précises, contraintes de vie privée, contraintes d'accessibilité et revue par des personnes qui ne sont pas toujours d'accord.
Pourquoi la sécurité du navigateur a besoin de primitives antifraude
Le dépôt des cas d'usage de l'AFCG décrit clairement la surface de menace. Il couvre la fraude à la création de comptes, la prise de contrôle de compte, le credential cracking, le credential stuffing, le phishing, le vol de tokens, le trafic invalide publicitaire, la fraude ecommerce, le carding, le card cracking, le cashing out, l'abus de promotions, le scraping, le spam, les faux engagements, le déni de service et les accès non autorisés.
Ces sujets ne sont pas séparés de la sécurité du navigateur. Ils sont de la sécurité du navigateur.
La plupart des défenses antifraude actuelles reposent sur des signaux fragiles :
- Réputation IP qui casse face aux proxies, VPNs et CGNAT
- Empreintes d'appareil qui créent des problèmes de suivi et de consentement
- CAPTCHA qui déplacent le coût vers les vrais utilisateurs et les équipes accessibilité
- Limites de débit côté serveur qui ne voient pas ce qui s'est passé dans le navigateur
- Défis antibot qui bloquent l'automatisation légitime et la navigation assistée
La plateforme web a besoin de meilleures primitives. Une bonne primitive doit répondre à une question étroite sans révéler plus que nécessaire. Elle doit aider un site à défendre un parcours sensible sans lui permettre de suivre l'utilisateur partout sur le web.
Cet équilibre compte. Les signaux antifraude doivent être assez forts pour arrêter l'abus, mais assez contraints pour ne pas devenir de nouveaux systèmes de pistage. Les preuves à connaissance nulle et l'inférence sur l'appareil rendent de nouveaux modèles possibles : le navigateur peut prouver un fait borné ou classifier localement un comportement à risque sans exposer d'identifiants bruts, d'historique de navigation ou d'empreintes d'appareil à chaque site.
Propositions actives à suivre
Plusieurs propositions et discussions montrent la direction du travail.
Private Access Control Tokens
Private Access Control Tokens (PACT) est l'un des travaux récents les plus importants. L'issue a été ouverte le 2025-12-02 comme déclaration conjointe du problème par Dennis Jackson, Sam Schlesinger et Eric Trouton.
PACT explore un mécanisme web capable de réduire la friction des CAPTCHA tout en permettant aux sites d'imposer des limites de débit face au trafic non désiré à fort volume. L'objectif de conception est explicite : préserver la vie privée, éviter le suivi entre sessions et ne pas exclure les utilisateurs selon leur matériel, leur plateforme ou leur user agent.
La proposition compte aussi pour le contrôle d'accès. Un utilisateur peut devoir prouver qu'il possède un compte valide et en règle sans révéler les ressources auxquelles il accède. Cela devient plus important à mesure que des agents IA locaux dans le navigateur agissent pour le compte des utilisateurs et déclenchent des signaux d'automatisation que beaucoup de sites bloquent aujourd'hui.
Private State Tokens
Private State Tokens vient du travail sur la Trust Token API. L'idée est de permettre à un émetteur de fournir des tokens cryptographiques au navigateur lorsqu'un utilisateur est jugé fiable, puis de permettre la rédemption de ces tokens plus tard dans un autre contexte sans exposer d'identifiant stable entre sites.
Ce type de mécanisme est fondamental pour des signaux de confiance respectueux de la vie privée. Il ne résout pas tous les scénarios d'abus, mais il va dans la bonne direction : transmettre un signal borné, garder les tokens bruts hors de JavaScript et éviter de donner aux sites un nouveau moyen de pistage.
Device Integrity Attestation
La discussion Device Integrity Attestation rassemble des cas d'usage et exigences pour des signaux haute fidélité et faible entropie sur l'intégrité de l'appareil. L'objectif est d'aider à distinguer les environnements légitimes des environnements émulés, rootés ou falsifiés utilisés dans l'abus.
C'est un travail sensible. Les signaux d'intégrité peuvent améliorer la défense, mais ils peuvent aussi exclure des utilisateurs sur appareils anciens, systèmes d'exploitation alternatifs ou configurations respectueuses de la vie privée. C'est précisément pour cela que ce travail doit rester dans un forum de standards ouvert plutôt que devenir une fonction privée de fournisseur.
Pourquoi cela compte pour le travail de cside
cside travaille au niveau du navigateur. Nous surveillons quels scripts s'exécutent, ce qu'ils chargent, comment ils changent et comment le comportement côté navigateur affecte la sécurité, la vie privée, la fraude et la conformité.
Cette vision opérationnelle correspond à la mission de l'AFCG. Les équipes antifraude ont besoin de signaux assez précis pour agir. Les équipes vie privée ont besoin que ces signaux ne deviennent pas de nouveaux identifiants. Les équipes sécurité ont besoin de visibilité au niveau du navigateur parce que les journaux serveur manquent le code qui s'exécute sur la machine de l'utilisateur.
Le travail de standardisation ne remplacera pas la sécurité navigateur en runtime. Il peut rendre la plateforme sous-jacente plus sûre et donner aux défenseurs de meilleurs outils que l'empreinte, le pistage et les défis brutaux.
Merci à Sam Schlesinger et Google
Ce travail dépend de personnes qui se présentent, rédigent des propositions, acceptent la revue et gardent les compromis difficiles au premier plan. Je veux remercier Sam Schlesinger et l'équipe Google pour l'opportunité d'aider à diriger ce travail ensemble.
Le travail de Sam sur les protocoles respectueux de la vie privée, PACT et Private State Tokens a orienté la direction technique de l'AFCG. Cette profondeur compte, car les standards antifraude doivent résister à la pression des attaquants comme à la revue vie privée.
Ce rôle prolonge naturellement le travail déjà mené par cside au W3C. Depuis notre arrivée dans le W3C Web Application Security Working Group en 2024, nous défendons un modèle plus fort de sécurité du navigateur. L'AFCG nous donne un autre lieu pour apporter des preuves opérationnelles de runtime dans le processus de standardisation.
Comment participer
L'AFCG est ouvert à la participation. Si votre équipe travaille sur la fraude, la sécurité du navigateur, les signaux respectueux de la vie privée, l'infrastructure cloud, les agents IA, les paiements, l'intégrité publicitaire ou la prévention des abus, le groupe a besoin de praticiens qui comprennent la réalité opérationnelle.
Commencez par la page du groupe W3C et les dépôts GitHub publics de cas d'usage et de propositions. Lisez les issues ouvertes. Ajoutez des cas d'usage concrets. Contestez les hypothèses faibles. Apportez tôt les contraintes d'implémentation.
Le navigateur évolue vite. Les standards qui gouvernent la sécurité du navigateur et les signaux antifraude doivent suivre ce rythme.
Au 2026-05-12, les propositions de l'AFCG restent des discussions publiques actives. L'état d'implémentation, le support navigateur et les destinations de standardisation peuvent changer.
