En bref : travaux de normalisation antifraude navigateur
- Ouvert, pas propriétaire : Le travail antifraude n'a pas sa place dans le coffre-fort d'un fournisseur privé. La fraude échoue à la revue publique, c'est pourquoi cside copréside le W3C Anti-Fraud Community Group avec Sam Schlesinger de Google au lieu d'expédier du fingerprinting caché derrière un login.
- Les vieux signaux échouent : La réputation IP casse sous CGNAT, les empreintes heurtent les lois sur le consentement et les CAPTCHA reportent le coût sur les vrais utilisateurs. cside apporte des preuves d'exécution navigateur à des propositions ouvertes comme PACT (ouverte le 2 décembre 2025) et Private State Tokens.
- À vous de choisir : Si votre programme antifraude dépend encore d'empreintes d'appareil, décidez maintenant si vous voulez participer aux standards qui les remplaceront ou être client de ce qui survivra.
Peu de temps ? Découvrez le blocage Magecart et skimmer dans le navigateur de cside. Elle couvre tout ce qui suit en un seul déploiement.
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.
Nommer les attaques est la partie facile. Les arrêter, sans transformer le navigateur en couche de surveillance ni forcer chaque utilisateur légitime à répéter des CAPTCHA, voilà ce qui est difficile.
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 API 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 entre elles.
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 e-commerce, 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.
Cette liste de menaces, c'est la sécurité du navigateur.
La plupart des défenses antifraude actuelles reposent sur un mélange de signaux fragiles :
- Une réputation IP qui casse face aux proxies, aux VPN et au CGNAT
- Des empreintes d'appareil qui créent des problèmes de suivi et de consentement
- Des CAPTCHA qui déplacent le coût vers les vrais utilisateurs et les équipes accessibilité
- Des limites de débit côté serveur qui ne voient pas ce qui s'est passé dans le navigateur
- Des 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, les VPN et le 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 limitation de débit 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 à divulgation nulle de connaissance et l'inférence sur l'appareil rendent de nouveaux modèles possibles : le navigateur peut prouver un fait borné ou classer 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 fils de discussion montrent la direction que prend ce 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 en tant que 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 avoir besoin de prouver qu'il détient un compte valide et en règle sans révéler quelles ressources il consulte. 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 est issu du travail sur la Trust Token API. L'idée est de permettre à un émetteur de fournir des tokens cryptographiques à un 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 transmet un signal borné, garde les tokens bruts hors de portée de JavaScript et évite de donner aux sites un nouveau levier de pistage.
Device Integrity Attestation
La discussion Device Integrity Attestation rassemble des cas d'usage et des 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 usurpé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 des appareils anciens, des systèmes d'exploitation alternatifs ou des 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 d'être traité comme une fonctionnalité 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 pouvoir agir, tandis que les équipes vie privée ont besoin que ces mêmes signaux ne deviennent pas de nouveaux identifiants. Les équipes sécurité ont aussi besoin de visibilité au niveau du navigateur, car 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é du navigateur en runtime. Il peut rendre la plateforme sous-jacente plus sûre et donner aux défenseurs de meilleurs outils que le fingerprinting, 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 en ligne de mire. Je tiens à remercier Sam Schlesinger et l'équipe de Google pour l'opportunité de contribuer à 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 survivre à la fois à la pression des attaquants et à la revue vie privée.
Ce rôle prolonge naturellement le travail déjà mené par cside au W3C. Depuis notre entrée dans le W3C Web Application Security Working Group en 2024, nous militons pour un modèle plus solide de sécurité du navigateur. L'AFCG nous donne un lieu supplémentaire 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 régissent la sécurité du navigateur et les signaux antifraude doivent suivre ce rythme.
En date du 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.
