Le 1er septembre 2026, CrowdSec 1.8 est sorti — et dans le WAF open-source, qui s'installe sur son serveur avec une seule helm install, deux choses sont arrivées en même temps : le fingerprinting de navigateur et le proof-of-work. Jusqu'à présent, le mur PoW était principalement rencontré dans la nature sauvage sur des git-forges et des archives de mailing. Maintenant, ce type de couche peut se retrouver sur n'importe quel site avec cinq cents visiteurs par jour.
Nous examinons ce qui a changé, pourquoi la détection a pris la direction du « payez avec le processeur », et — surtout — pourquoi le hachage dans cette construction est le moindre des problèmes.
Ce qui s'est passé : le PoW est descendu des git-forges vers des sites ordinaires
CrowdSec est un système auto-hébergé : l'agent lit les journaux, le WAF se trouve devant l'application, les « bounceurs » bloquent. Dans la version 1.8, l'équipe a ajouté au WAF un mécanisme qui ne répond pas à la question « cet IP est-il mauvais ? », mais à la question « est-ce un vrai navigateur avec un humain ou un bot qui fait semblant d'en être un ? ». La réponse est collectée à partir du fingerprint (caractéristiques du navigateur et signature TLS) et du proof-of-work — une tâche computationnelle que le client doit résoudre avant que le backend ne voie la requête.
Les auteurs formulent la motivation sans diplomatie : le bot moyen de 2026 arrive avec un vrai Chrome, un fingerprint TLS cohérent, un IP résidentiel — et il a plus de patience qu'un ingénieur de garde. Cette reconnaissance de la part de la détection vaut plus que n'importe quelle analyse : l'adresse résidentielle et un TLS soigné ont cessé d'être un signe distinctif. Puisque, par réputation IP et poignée de main, le bot ne se distingue plus de l'humain, la protection cherche un signe qui est bon marché pour le navigateur et coûteux pour le parc de machines.
Parallèlement, sur Hacker News, POWBlock — « un microservice proof-of-work pour n'importe quel serveur » — a également fait surface ces jours-là. Un lancement peut être attribué à une coïncidence, deux signaux indépendants en une semaine — c'est déjà une direction.
Comment fonctionne le mur PoW à l'exemple d'Anubis
L'étalon du genre est Anubis : un reverse proxy en Go sous licence MIT, écrit par Xe Iaso sous la marque Techaro depuis janvier 2025. L'idée vient directement du hashcash d'Adam Back de 1997 : le client essaie des valeurs jusqu'à ce que le SHA-256 donne un hachage avec le bon nombre de zéros en tête. Résolu — vous obtenez un cookie JWT signé (techaro.lol-anubis-auth) et un accès temporaire. Non résolu — le backend ne vous connaîtra pas.
La difficulté est définie par l'administrateur. Par défaut, Anubis challenge tout ce qui ressemble à un navigateur — c'est-à-dire tout ce qui a dans son User-Agent la chaîne Mozilla. Ce que coûte chaque niveau est montré par les mesures :
- Difficulté 1 — moins de 100 ms.
- Difficulté 4 (défaut) — environ 1,35 s sur Intel Core Ultra 7 165H, soit environ 87 600 hachages par seconde dans le navigateur.
- Difficulté 8 — environ 11 s.
- Difficulté 10 — environ 114 s.
Entre le quatrième et le dixième niveau, la différence est d'environ 84 fois. La liste des intégrateurs est impressionnante : l'archive de mailing du noyau Linux et le serveur git du noyau, sourcehut, FFmpeg, GitLab du projet GNOME, Wine, sourceware.org, FreeCAD, ScummVM, Enlightenment, UNESCO. À l'université de Duke, un pilote en juin 2025 a filtré plus de 4 millions de requêtes HTTP indésirables par jour — environ 90 % du trafic indésirable — et en une semaine, 12 personnes se sont plaintes de problèmes.
Ces murs n'ont pas émergé par malice. Chez Read the Docs, un seul crawler a téléchargé 73 To en un mois ; après le blocage, le trafic quotidien est tombé de 800 Go à 200 Go, une économie d'environ 1500 dollars par mois. Drew DeVault a décrit que la lutte contre les crawlers lui coûtait entre 20 et 100 % de certaines semaines. Sur fond d'une augmentation du trafic automatisé de 23,51 % en 2025 et d'une presque multiplication par trois du trafic AI au cours de l'année, les administrateurs se sont attaqués à ce qui fonctionne rapidement.
Un tournant : contre le parsing industriel, le PoW fonctionne presque pas
Et maintenant, la partie délicate, qui est rarement écrite dans les communiqués de presse. Le proof-of-work repose sur l'asymétrie « facile à vérifier, coûteux à résoudre ». Dans le web, cette asymétrie est déployée dans le mauvais sens.
Un visiteur honnête considère les hachages comme un JavaScript lent dans le navigateur. Celui qui vient pour les données les considère comme du code natif. Tavis Ormandy a écrit un solveur en 25 lignes de C : une tâche de difficulté 5 se ferme en environ 0,017 seconde — c'est environ 200 fois plus rapide que SubtleCrypto dans le navigateur. Sur GPU, l'écart est encore plus grand, d'environ cent fois et plus. Le résultat de l'arithmétique est simple : pour un grand fournisseur, contourner tous les sites Anubis coûte presque rien.
Ce n'est pas une théorie. Codeberg a déjà signalé en août 2025 que de nombreux bots scraper ont appris à résoudre les défis Anubis. Le mur, cependant, n'est pas devenu inutile — pendant plusieurs mois, il a filtré la majorité — mais comme barrière pour ceux qui sont prêts à investir une soirée dans un solveur natif, il ne tient pas.
Comme d'habitude, c'est l'utilisateur vivant qui paie la facture. La difficulté 5 — c'est environ 2 secondes sur un MacBook récent, des dizaines de secondes sur un ancien ordinateur portable et jusqu'à deux minutes sur un téléphone. Sur GitLab GNOME, un cas de blocage de trente minutes dans Firefox a été enregistré — une anomalie, mais révélatrice. De plus, des exceptions strictes : par défaut, Anubis exige JavaScript, donc les lecteurs RSS, curl, wget et Lynx échouent simplement. Le projet corrige cela — dans la version 1.20.0, un chemin sans JS via meta-refresh a été introduit — mais dans la 1.22.0, le Proof of React est arrivé, qui, au contraire, a augmenté les exigences pour le navigateur.
Il convient également de noter la durabilité du projet lui-même : environ la moitié du code est committée par une seule personne, et parmi les 80+ contributeurs, un seul autre développeur a dépassé une dizaine de commits. De plus, Anubis intègre un service payant Thoth pour le filtrage GeoIP et BGP — c'est-à-dire qu'un projet open-source a un voisin commercial.
Où le PoW mord vraiment : la version commerciale est différente
C'est ici que se cache la principale substitution de concepts. Kasada, hCaptcha et Cloudflare Turnstile utilisent également le proof-of-work — mais pas du tout comme Anubis.
Avec Anubis, le puzzle est le mur : exécutez JS, calculez le hachage — vous passez. Un signal, une barrière. Dans les systèmes commerciaux, le PoW fonctionne comme une attestation. Chez Kasada, la tâche prend quelques millisecondes — si peu que comme barrière, elle est sans signification. Le sens est autre : pour la résoudre, le client doit exécuter une machine virtuelle obfusquée, à l'intérieur de laquelle se déroule la véritable détection. Vous calculez le hachage sans avoir exécuté tout le reste — vous ne recevrez rien. hCaptcha superpose le PoW au verdict sur les images, augmentant le coût computationnel pour les clients suspects, Turnstile considère le PoW comme un signal parmi de nombreux tests d'environnement.
La différence est fondamentale. Le mur ouvert est brisé par un solveur natif bon marché. Le commercial est brisé non par le hachage, mais par la nécessité d'exécuter honnêtement le code obfusqué d'autrui et de ne pas se faire prendre dans l'environnement — et cela coûte cher, car l'obfuscation est régulièrement renouvelée. CrowdSec 1.8 est intéressant précisément parce qu'il tire un hybride de cette logique (fingerprint à côté du PoW) dans le monde auto-hébergé, où auparavant il n'y avait qu'une limite de taux par IP.
Ce que cela change en pratique
Si vous collectez des données légalement — surveillez les prix, suivez votre marque, menez des recherches — les conclusions sont assez concrètes.
- Le problème n'est pas dans le hachage, mais dans la couche de navigateur. Le hachage est calculé nativement en millisecondes. Le fingerprint, la VM obfusquée et l'environnement correct ne le sont pas. Le changement pratique : là où un client HTTP suffisait auparavant, un véritable moteur de navigateur est désormais nécessaire. Cela coûte plus cher en CPU et en mémoire, et il faut planifier cela dès le départ.
- L'économie passe du trafic au temps et au processeur. Auparavant, le coût était calculé en IP et en gigaoctets. Maintenant, il faut ajouter des secondes par page et la charge des cœurs. Il faut mesurer non le coût par gigaoctet, mais le coût d'un enregistrement réussi — avec le mur PoW, ces deux métriques divergent particulièrement fortement.
- La session devient un actif. Anubis délivre un cookie JWT pour un temps limité. Si vous changez d'IP après chaque requête, vous payez à nouveau le « taxe PoW » sur chaque page. Les sessions collantes sur des proxies résidentiels offrent un avantage non pas en « anonymat », mais directement en calculs : une solution de problème est amortie sur des dizaines de pages. Une rotation agressive dans le monde du PoW devient une surconsommation.
- Le solveur ne remplace pas le comportement. La même logique selon laquelle les solveurs de captcha ont cessé de résoudre le problème : vous résolvez une tâche visible, mais le verdict est rendu sur des signaux invisibles autour d'elle.
- Réduisez la fréquence — c'est moins cher que n'importe quel mur. La vague PoW a grandi à partir d'histoires comme 73 To en un mois avec un seul crawler. Le cache, les requêtes conditionnelles, un intervalle raisonnable et le respect de robots.txt vous retirent du radar avant que le défi ne s'active. Des adresses de centre de données bon marché plus un headless à la fréquence maximale — c'est exactement le profil pour lequel les murs sont installés.
Conclusion
CrowdSec 1.8 n'est pas « la fin du scraping », et Anubis ne l'est pas non plus : un solveur natif résout une tâche de difficulté 5 en 0,017 seconde, tandis qu'un humain sur un ancien téléphone attend jusqu'à deux minutes. La véritable nouvelle est ailleurs. Premièrement, la détection a publiquement reconnu que l'IP résidentielle et un TLS propre ne prouvent plus rien. Deuxièmement, la couche « prouve que tu es un navigateur » a cessé d'être un privilège des grandes plateformes avec un budget pour Kasada et a déménagé dans l'open-source, qui s'installe sur des sites ordinaires.
Il faut se préparer non à une bataille avec des hachages, mais à ce que le schéma bon marché « beaucoup d'IP plus un client HTTP rapide » va échouer sur des cibles de plus en plus petites. La configuration gagnante est opposée : moins de requêtes, un vrai navigateur, de longues sessions et des adresses de qualité là où un passage fiable est nécessaire, et non mille tentatives bon marché.