Serveur CAPTCHA en Rust, widget de preuve de travail en iframe
mCaptcha est un serveur CAPTCHA écrit en Rust, à héberger soi-même. Sur le formulaire protégé, le visiteur clique sur une case, et son navigateur calcule une preuve de travail SHA-256 dans un widget que l'instance mCaptcha sert en iframe. L'instance vérifie la preuve et rend un jeton, que le backend du site lui soumet avant d'accepter le formulaire. Un tableau de bord gère les comptes et les clés de site.
Le calcul demandé s'alourdit quand le nombre de visiteurs du site augmente. ALTCHA et Cap font eux aussi payer le navigateur en calcul, le premier comme bibliothèque branchée sur le backend existant, le second en bibliothèque ou en serveur autonome.
Le comparatif des CAPTCHA hébergés chez soi confronte ce que la preuve de travail de mCaptcha arrête à ce qu'arrêtent les autres outils.
Difficulté indexée sur le trafic, sans cookie ni limite par IP
- Une difficulté indexée sur le trafic : pour chaque clé de site, un compteur augmente à chaque visite et redescend après une période de refroidissement, et chaque palier de visiteurs a son facteur de difficulté. Le README annonce un délai nul sous charge modérée et jusqu'à 2 secondes de calcul sous attaque.
- Trois paliers en mode simple : on saisit le trafic moyen, le pic que le site supporte et, en option, le volume qui l'a déjà fait tomber. Les facteurs par défaut vont de 50 000 à 5 000 000. Le mode avancé règle chaque palier à la main.
- Une preuve qui ne se rejoue pas : chaque configuration de preuve expire au bout de 30 secondes et ne sert qu'une fois.
- Pas de cookie ni de limite par adresse IP : les routes du CAPTCHA ne posent pas de cookie selon le README, et le site du projet dit ne pas limiter le débit par IP, ce qui épargne les visiteurs derrière un NAT.
- Un chemin sans JavaScript : un outil en ligne de commande calcule la preuve à partir de l'URL de la page, et le visiteur colle le code obtenu dans le formulaire.
- Widget pour JavaScript, React et Svelte, en paquets npm sous MIT ou Apache-2.0, au choix.
Mainteneur désillusionné, seule version publiée en mars 2024
Postgres dans la documentation, Redis pour passer à plusieurs instances. Le Compose fourni lance mCaptcha, Postgres 18 et mcaptcha/cache, un Redis doté d'un module maison qui tient les compteurs de visiteurs. Sans Redis, ces compteurs restent dans la mémoire du processus, sur une seule instance. Le code accepte aussi MySQL ou MariaDB, que la documentation ne décrit pas. Aucun besoin en mémoire ni en processeur n'est documenté (ticket #189, ouvert depuis août 2025), et les images Docker publiées n'existent qu'en amd64.
Les identifiants du README n'ouvrent pas le premier compte. Le compte aaronsw n'existe qu'en mode démo, que .env.docker-compose désactive comme l'inscription : il faut ouvrir celle-ci le temps de créer son compte (ticket #197).
La vérification côté serveur n'a pas le format de reCAPTCHA. Le site annonce des API compatibles avec reCAPTCHA et hCaptcha, mais le POST /api/v1/pow/siteverify documenté attend en JSON token, key et secret et répond valid, là où reCAPTCHA attend secret et response et répond success. Le contrôle du backend est donc à réécrire. L'extrait HTML de la documentation charge en outre le script d'intégration du widget depuis unpkg.com.
AGPL-3.0-or-later pour le serveur, aucune offre payante. Qui expose une version modifiée du serveur en service réseau doit en publier le code. Le site du projet ne propose ni hébergement ni formule payante.
Le mainteneur ne croit plus à la preuve de travail. En juin 2025, une analyse publiée dans le ticket #186 a produit environ 250 preuves valides par seconde avec un seul processeur Ryzen 9 7950X, au palier le plus difficile par défaut, quand le serveur ne traitait qu'environ 650 requêtes par seconde de preuves invalides. Le mainteneur a confirmé ces résultats en juin 2026. Il s'y dit « désillusionné » par la preuve de travail, qui ne coûte presque rien aux robots d'indexation des LLM, et écarte les parades contre le calcul SIMD ou ASIC, qui pénaliseraient les visiteurs ordinaires. Son plan : mettre à jour les dépendances, publier une version, puis concevoir autre chose.
Une version publiée, aucun commit depuis un an. La v0.1.0 du 15 mars 2024 reste la seule. Le dernier commit date du 7 octobre 2025, et l'image latest que tire le Compose date de ce même jour, pas de la v0.1.0. Le README affiche toujours « active development ». Un développeur signe 761 des 879 commits.