Qu'est-ce qu'un CAPTCHA ? Comment il fonctionne, ce qu'il coûte, ce qui le remplace

Comment fonctionne un CAPTCHA

CAPTCHA signifie, en anglais, « test de Turing public et entièrement automatisé pour distinguer les ordinateurs des humains ». Des chercheurs de l'université Carnegie Mellon ont forgé le terme en 2003, et l'idée n'a pas changé depuis : poser une question facile pour un humain et difficile pour un programme, et n'accepter la requête que si la réponse est juste.

Tout CAPTCHA, du mot tordu au contrôle invisible, fonctionne en trois temps. Le widget s'exécute dans le navigateur du visiteur et produit un jeton (token), la preuve qu'un défi a été réussi. Le navigateur envoie ce jeton avec le formulaire. Votre serveur demande ensuite au fournisseur du CAPTCHA si le jeton est authentique, avant de créer le compte ou d'envoyer le message.

C'est la troisième étape qu'on oublie, et sans elle le widget n'est qu'un décor : un bot poste le formulaire sans jeton, ou avec un vieux, et passe. C'est pour cela que les jetons expirent vite et ne servent qu'une fois : la vérification doit se faire côté serveur, à chaque envoi.

Vérification côté serveur : l'étape qui donne un sens au widget

curl -s https://www.google.com/recaptcha/api/siteverify \
  -d secret="$RECAPTCHA_SECRET" \
  -d response="$JETON_DU_FORMULAIRE"

# {"success": true, "hostname": "example.com", ...}
# hCaptcha et Turnstile fonctionnent de la même façon, chacun avec sa propre URL siteverify.

Les types : des lettres tordues au contrôle sans énigme

Les CAPTCHA textuels affichent des lettres et des chiffres déformés. C'était la première génération, et c'est aujourd'hui la plus faible : les logiciels de reconnaissance de caractères les lisent mieux que beaucoup d'humains.

Les CAPTCHA à images demandent de cocher toutes les cases contenant un feu tricolore ou un vélo. Les CAPTCHA audio dictent des chiffres sur un bruit de fond et existent surtout comme alternative accessible aux deux premiers.

reCAPTCHA v2, la case de Google, a changé le modèle en 2014. Cocher « Je ne suis pas un robot » est surtout l'occasion pour le script d'observer le navigateur et son comportement ; seul le visiteur dont il doute reçoit la grille d'images. Sa variante invisible supprime même la case et n'affiche la grille qu'au besoin.

reCAPTCHA v3 (2018) n'affiche rien du tout. Il renvoie un score entre 0.0 et 1.0 pour chaque action, et c'est votre serveur qui décide de ce que signifie un score bas : refuser, demander un second facteur ou envoyer la soumission en modération.

hCaptcha suit le modèle de la v2, avec des contrôles en arrière-plan et une tâche d'images en cas de doute, et se positionne sur la confidentialité ; son offre entreprise ajoute des scores de risque.

Cloudflare Turnstile (2022) remplace l'énigme par un ensemble tournant de contrôles non interactifs exécutés dans le navigateur, et il est gratuit sur n'importe quel site, pas seulement derrière Cloudflare. Son widget a trois modes : géré (une case seulement si les contrôles hésitent), non interactif et invisible.

La tendance saute aux yeux : chaque génération demande moins au visiteur et davantage au navigateur.

Ce qu'un CAPTCHA vous coûte

Du temps, et les conversions qui vont avec. Une vaste étude de Stanford publiée en 2010 a mesuré environ 10 secondes pour résoudre un CAPTCHA à images et près de 30 secondes pour un CAPTCHA audio, dont les réponses étaient souvent fausses. Chacune de ces secondes s'interpose entre le visiteur et ce qu'il était venu faire : s'inscrire, payer, vous poser une question.

L'accessibilité. Une énigme visuelle exclut les personnes aveugles et malvoyantes, et l'alternative audio est difficile pour tout le monde et inutilisable pour qui ne voit ni n'entend bien. Le W3C a publié une note entièrement consacrée à l'inaccessibilité des CAPTCHA, et les WCAG exigent qu'un CAPTCHA propose une alternative destinée à un autre sens.

La confidentialité et le poids de la page. Le widget est un script du fournisseur, chargé sur votre page, qui voit le navigateur du visiteur : cela a sa place dans votre politique de confidentialité. C'est aussi un morceau conséquent de JavaScript tiers ; chargez-le uniquement sur la page qui porte le formulaire, jamais sur tout le site.

Se tromper sur les gens. Les systèmes fondés sur le risque apprennent à quoi ressemble un trafic typique, et l'utilisateur d'un VPN, d'un navigateur axé sur la confidentialité ou d'une connexion de bureau très partagée paraît moins typique. Il reçoit plus d'énigmes, ou un score plus bas, sans avoir rien fait de mal.

Pourquoi les énigmes ne suffisent plus

Un CAPTCHA ne fonctionne que tant qu'il est moins coûteux à résoudre pour un humain que pour une machine. Ce n'est plus vrai depuis un moment.

Les machines ont progressé. Les CAPTCHA textuels sont tombés d'abord face à la reconnaissance de caractères, les grilles d'images ensuite face aux modèles de vision modernes. Une étude présentée à USENIX Security en 2023 a constaté que des bots résolvaient plusieurs types de CAPTCHA très répandus plus vite que les humains, et le texte déformé avec plus de précision.

Les humains sont devenus bon marché. Là où le logiciel échoue, des services de résolution de CAPTCHA confient l'énigme à des travailleurs humains et renvoient la réponse par une API, pour quelques dollars les mille résolutions. Pour un spammeur, c'est une broutille ; pour vos vrais visiteurs, l'énigme reste le même agacement de dix secondes.

Aujourd'hui, un CAPTCHA filtre donc surtout l'automatisation bon marché : des scripts qui ne cherchent même pas à ressembler à un navigateur. À l'entrée d'un formulaire, cela vaut encore la peine. Mais ce n'est pas une défense pour le reste du site, et la valeur des systèmes modernes tient aux signaux qu'ils collectent, pas à l'énigme qu'ils affichent de temps en temps.

Les alternatives invisibles

Voici les contrôles qui remplacent l'énigme. Aucun ne demande quoi que ce soit au visiteur, et ils sont plus forts ensemble.

Le JS challenge (défi JavaScript). Le serveur répond à une première requête suspecte par une petite page qui exécute un script dans le navigateur. Un vrai navigateur le termine en une seconde environ et reçoit un cookie signé ; un script qui se contente de télécharger du HTML ne va pas plus loin. Le visiteur voit une brève page « vérification de votre connexion », ou rien du tout.

La preuve de travail. Une variante où le navigateur résout un petit calcul. Les humains ne s'en aperçoivent pas, mais chaque requête coûte au bot du temps processeur, ce qui finit par peser à grande échelle.

La limitation de débit. Elle compte les requêtes de chaque client dans le temps. Un humain lit une page et clique sur quelques liens par minute ; un scraper en fait des centaines. Compter révèle un comportement qu'aucune requête isolée ne trahit.

Les scores de bots et les signaux de risque. D'où vient la requête (une connexion résidentielle ou un réseau de datacenter), ses en-têtes correspondent-ils au navigateur qu'elle prétend être, comment se comporte-t-elle d'une requête à l'autre. Certains systèmes résument tout cela en un score, d'autres agissent sur des signaux nommés. Dans les deux cas, la décision est prise avant que la page soit servie.

Les champs pièges (honeypot). Un champ de formulaire masqué aux humains par CSS. Les humains le laissent vide ; les bots naïfs remplissent tous les champs et se trahissent. Gratuit, invisible et efficace contre le spam bon marché.

Les robots d'indexation vérifiés. Les moteurs de recherche doivent traverser tout cela sans encombre. On les reconnaît au réseau d'où ils viennent, pas à leur user agent, une chaîne que n'importe qui peut écrire.

Où un CAPTCHA a encore sa place

Sur un formulaire où un seul envoi réussi rapporte quelque chose à un attaquant : création de compte, réinitialisation de mot de passe, formulaires de contact et de commentaires, champs de cartes cadeaux et de codes promo. Là, une étape de plus pour un humain est un prix raisonnable, et un jeton vérifié côté serveur est exactement le bon contrôle.

C'est ainsi que nous l'utilisons nous-mêmes. Les formulaires d'inscription et de contact de cdn.com.tr portent un CAPTCHA à case, et sur la page des tarifs le script du CAPTCHA ne se charge qu'à l'ouverture du formulaire de contact entreprise : personne ne le télécharge en consultant les prix.

Là où il n'a pas sa place : la navigation ordinaire, les listes de produits, les articles, les API et les applications mobiles. Une énigme devant la navigation taxe chaque visiteur pour arrêter un trafic qu'un contrôle invisible en bordure arrête mieux.

Comment CDN.com.tr protège un site sans énigme

La protection anti-bots de cdn.com.tr est un défi JavaScript qui s'exécute en bordure (edge), devant votre serveur d'origine. Dans le panneau, c'est la carte Protection anti-bots (JS Challenge), dans la section Protection, avec trois modes : désactivé, visiteurs à risque (recommandé) et tout le monde. Un changement de mode atteint l'edge tout seul ; il n'y a rien à déployer.

En mode visiteurs à risque, seules les requêtes porteuses d'un signal de risque sont vérifiées : le trafic issu de réseaux de datacenters et de cloud, d'où les vrais lecteurs naviguent rarement ; un client qui se dit moteur de recherche mais arrive d'un réseau que ce moteur n'utilise pas ; un user agent absent ou presque vide ; et une rafale de pages vues depuis une même adresse. Un lecteur sur une connexion résidentielle ou mobile ne voit rien.

Seules les navigations de page sont vérifiées. Images, feuilles de style, scripts, appels d'API et envois de formulaires passent sans être touchés : votre taux de succès du cache et vos applications ne sont pas affectés. Les robots vérifiés des moteurs de recherche (Google, Bing, Yandex, Apple et DuckDuckGo) passent toujours, contrôlés d'après le réseau d'où ils viennent réellement et non d'après le nom qu'ils annoncent : le défi ne vous coûte jamais d'indexation.

Le visiteur vérifié voit pendant une seconde environ une courte page « Vérification de votre connexion » dans sa langue (sept sont intégrées, l'anglais pour les autres), puis la page demandée. La page de vérification part en 503 avec noindex, elle ne peut donc jamais se retrouver dans les résultats de recherche. Un visiteur qui l'a passée n'est plus sollicité pendant 30 minutes, et le cookie d'autorisation est lié à son adresse et à son navigateur : impossible de le copier sur une autre machine.

Le mode tout le monde fait passer par la vérification la première page vue de chaque nouveau visiteur. C'est un levier pour le cœur d'une attaque, pas un réglage pour les jours ordinaires, et le panneau demande une confirmation avant de l'activer.

Ce qu'il a arrêté, et ce qu'il y a derrière

C'est le plafond de tout défi JavaScript : un bot qui pilote un vrai navigateur peut exécuter le script. C'est pourquoi le défi n'est qu'une couche parmi d'autres sur le même edge. Une limitation de débit, définie pour tout le compte ou par règle de diffusion et comptée par adresse client, répond par un 429 à tout ce qui dépasse son quota : c'est ce qui rend coûteuse une flotte de navigateurs headless. Le WAF inspecte ce que transportent les requêtes, et les règles par pays et par ASN ferment par un 403 un réseau dont vous ne voulez jamais entendre parler.

La carte du défi tient ses propres statistiques : vérifications affichées, vérifications réussies, robots vérifiés laissés passer, raisons des vérifications et réseaux les plus vérifiés, sur la dernière heure, le dernier jour, la dernière semaine ou le dernier mois. Un taux de réussite proche de zéro est le résultat recherché : ce qui a été arrêté n'était pas humain.

Quel outil pour quel cas

Pages aspirées ou inondées par des clients qui ressemblent à des navigateurs : la protection anti-bots en mode visiteurs à risque.

Une attaque en cours : le mode tout le monde le temps qu'elle dure, puis retour aux visiteurs à risque.

Des tentatives de deviner les mots de passe sur la page de connexion : une limitation de débit stricte sur ce chemin, et un CAPTCHA sur le formulaire.

Des inscriptions et messages de contact indésirables : un CAPTCHA ou Turnstile sur le formulaire, vérifié côté serveur, plus un champ piège.

Du trafic venant d'un réseau que vous ne servez jamais : une règle par ASN ou par pays.

Des charges malveillantes comme l'injection SQL : le WAF. Le défi vérifie qui demande, pas ce qui est envoyé. Pour les attaques volumétriques, voyez la protection DDoS.