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.
| Modèle d'abus | Dépendance à la session du navigateur | Pourquoi les journaux serveur manquent le contexte |
|---|---|---|
| Credential stuffing | Les tentatives de connexion automatisées passent par de vrais flux navigateur | Les journaux serveur voient les requêtes, pas le comportement client |
| Prise de contrôle de compte | Le comportement de session, les scripts et les interactions comptent | Les événements backend manquent la manipulation au runtime |
| Carding | L'automatisation du checkout se déroule dans les sessions navigateur | Les tentatives de paiement manquent de preuves côté navigateur |
| Scraping | Les clients automatisés imitent une navigation normale | L'IP et le débit de requêtes seuls sont des signaux faibles |
| Faux engagement | Les agents IA génèrent des flux d'interaction plausibles | Les événements d'engagement ne prouvent pas l'intention humaine |
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
| Défense actuelle | Ce qu'elle aide à traiter | Où elle casse | Meilleure primitive nécessaire |
|---|---|---|---|
| Réputation IP | Bloque l'infrastructure malveillante connue | Échoue avec les proxies, VPN et CGNAT | Signal de confiance navigateur étroit |
| Fingerprinting d'appareil | Distingue les clients récurrents | Crée des problèmes de suivi et de consentement | Preuve bornée respectueuse de la vie privée |
| CAPTCHA | Ajoute de la friction aux parcours suspects | Pénalise les utilisateurs légitimes et les équipes accessibilité | Contrôle d'abus à faible friction |
| Limites de débit côté serveur | Limite le volume de requêtes | Ne voit pas le comportement runtime du navigateur | Primitive de rate limiting consciente du client |
| Défis antibot | Filtre l'automatisation évidente | Bloque l'automatisation légitime et la navigation assistée | Signal d'automatisation respectueux de la vie privé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.
| Primitive ou contrôle | Risque pour la vie privée | Résistance à l'abus | Contrainte de standardisation |
|---|---|---|---|
| Limites de débit côté serveur | Faible | Faible | Utile, mais sans contexte navigateur |
| CAPTCHA | Faible à moyen (collecte de données par des tiers) | Moyenne | Ne doit pas devenir le chemin par défaut pour les utilisateurs légitimes |
| Fingerprinting brut d'appareil | Élevé | Élevée | Crée un risque de suivi et de consentement |
| Private State Tokens | Faible | Moyenne-élevée | Nécessite des signaux de confiance bornés et aucun identifiant stable intersites |
| Private Access Control Tokens | Faible | Élevée | Nécessite des limites de débit et un contrôle d'accès respectueux de la vie privée |
| Device Integrity Attestation | Moyen | Élevée | Nécessite des contraintes fortes pour éviter l'exclusion et le suivi |
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.
