De nombreuses implémentations CAPTCHA partagent l'IP client, l'empreinte navigateur, l'ensemble des headers et la télémétrie comportementale avec des services tiers au moment de la vérification. Ce modèle est acceptable dans certains secteurs, mais pour les environnements du secteur public, financier, de la santé et les environnements air-gap, il crée une exposition sérieuse en matière de résidence des données et de conformité.
Pour les organisations sensibles à la conformité, même un seul appel CAPTCHA sur un écran de connexion peut déclencher une discussion sur le transfert de données personnelles. Les exigences de consentement explicite, les règles de transfert transfrontalier, les garanties contractuelles et la dépendance vis-à-vis des fournisseurs peuvent transformer une simple décision de protection bot en un projet de conformité long.
La dépendance aux services CAPTCHA externes crée également un risque opérationnel. Lorsqu'un service de vérification tiers ralentit ou devient inaccessible, le flux de connexion, d'inscription ou de paiement de chaque application protégée est affecté. La protection bot devient une dépendance externe critique pour l'application.
Le bon modèle consiste à effectuer la génération, la diffusion et la vérification des challenges à l'intérieur de la couche ADC de l'organisation. Les données client restent locales, le processus de vérification est autonome, la difficulté s'adapte au risque du service et les tentatives échouées peuvent alimenter l'escalade en quarantaine.
TR7 CAPTCHA Auto-hébergé offre exactement ce modèle : il rend la vérification bot auto-hébergée, réduit le risque de résidence des données et s'intègre directement avec le pipeline de décision WAAP.
TR7 implémente le CAPTCHA via la génération locale, une difficulté réglable, des modes de vérification visibles et invisibles, et une escalade en quarantaine.
L'image CAPTCHA, le contenu HTML/JS, la signature de token et la vérification de solution s'exécutent toutes sur TR7. Aucun appel HTTP sortant vers un service externe n'est effectué pendant le processus de vérification.
La difficulté est évaluée conjointement avec la longueur des caractères, le bruit visuel, la charge PoW et le temps de résolution minimum. L'opérateur trouve le bon équilibre entre expérience utilisateur et résistance aux bots avec un seul paramètre.
La vérification visuelle peut être présentée aux clients à risque élevé. Pour les clients à risque moyen, la validation PoW peut s'exécuter silencieusement en arrière-plan sans présenter d'écran supplémentaire à l'utilisateur.
Le CAPTCHA n'est déclenché que lorsqu'un seuil de risque est franchi. Les mauvaises réponses sont suivies ; une fois le seuil dépassé, des actions de quarantaine telles que deny, redirect, contenu personnalisé ou code de statut personnalisé peuvent être appliquées.
Le CAPTCHA Auto-hébergé combine la génération de challenges auto-hébergée avec le scoring bot, le PoW, la sécurité des cookies et les flux de quarantaine.
TR7 génère l'image CAPTCHA en interne, sert la page de challenge depuis son propre service et vérifie les solutions via un processus helper local. L'IP client, le user agent et le résultat de vérification ne sont jamais envoyés à un service externe. Ce modèle offre un avantage critique pour les organisations soumises à des exigences de résidence des données. La protection CAPTCHA est appliquée sans aucune dépendance aux services externes.
Dans TR7, la difficulté est sélectionnée sur une échelle de 1 à 5. Cette valeur correspond à la profondeur de bits PoW (16–20 bits), la longueur des caractères CAPTCHA (4–7 caractères), la densité des lignes et points visuels, et un temps de résolution minimum imposé côté serveur. L'opérateur gère à la fois l'expérience humaine et le coût pour les bots avec un seul curseur. Les services à risque plus élevé peuvent être configurés avec une difficulté plus haute.
La validation PoW est appliquée dans le cadre de la vérification CAPTCHA. Le navigateur doit effectuer un calcul défini avant que la solution soit acceptée. Un temps de résolution minimum côté serveur est également imposé — même si un bot produit la bonne réponse instantanément, une solution qui arrive trop rapidement est traitée comme suspecte. Cette approche augmente le coût de l'automatisation tout en ajoutant une charge minimale aux utilisateurs réels.
Le token produit après une vérification réussie est transporté dans un cookie chiffré. Le token peut être lié à l'adresse IP du client et au contexte du user agent, rendant significativement plus difficile la réutilisation d'un token de vérification obtenu par un client dans un contexte différent. Pendant la fenêtre verifiedTtl, l'utilisateur réel n'a pas à résoudre le CAPTCHA à chaque requête.
TR7 peut affecter un processus helper dédié et un chemin de socket dédié à chaque règle CAPTCHA. Cet isolement réduit l'impact d'une défaillance ou d'un pic de charge dans une règle sur les autres règles. La séparation par pool signifie que les flux CAPTCHA pour différents services sont gérés indépendamment. scalingCount permet à plusieurs processus de s'exécuter pour la même règle.
Lorsque le type est défini sur text, l'utilisateur rencontre un CAPTCHA visuel. En mode invisible, la vérification basée sur PoW s'exécute sans présenter un écran de challenge complet. Les clients à risque moyen sont vérifiés avec moins de friction, tandis que les clients à risque plus élevé reçoivent le CAPTCHA visuel pour augmenter le coût pour les bots.
La couleur de fond, la couleur du texte, le thème et la taille peuvent être définis par service. Les tailles de CAPTCHA petite, moyenne et grande s'adaptent à différentes interfaces utilisateur. L'écran de vérification n'apparaît pas déconnecté de l'expérience de marque de l'organisation. Dans les scénarios SaaS B2B en marque blanche, chaque tenant peut offrir une expérience proche de sa propre identité visuelle.
Les titres CAPTCHA, les textes descriptifs et les messages d'erreur peuvent être liés à une structure multilingue. La langue peut être sélectionnée par service ou selon le contexte client. Cela fournit un flux de vérification plus clair dans les services du secteur public, financiers et multi-régions. L'ajout d'une nouvelle langue ne nécessite pas de modifier la logique de vérification.
Le CAPTCHA n'a pas à être affiché à chaque utilisateur par défaut. Le scoring bot TR7, la réputation IP, les signaux comportementaux et les conditions DDoS peuvent restreindre la présentation des challenges aux seuls clients risqués. Cela réduit la friction pour les utilisateurs réels. Le trafic de confiance continue sur le chemin normal tandis que le trafic suspect est acheminé vers la vérification.
Les mauvaises réponses CAPTCHA peuvent être suivies et, une fois un seuil défini dépassé, le client est mis en quarantaine. L'action de quarantaine peut être configurée comme deny, redirect, customContent ou customStatusCode. Cela empêche les bots de consommer continuellement des challenges pour épuiser le système. À mesure que les échecs s'accumulent, une action plus sévère remplace le challenge.
Lorsqu'un utilisateur passe le CAPTCHA avec succès, il peut être traité comme vérifié pendant une période configurée. Le même utilisateur n'est pas à nouveau confronté au CAPTCHA jusqu'à l'expiration de verifiedTtl. Cela préserve l'expérience de l'utilisateur réel tout en maintenant la barrière de vérification initiale contre les bots. La liaison IP+UA rend plus difficile le vol et la réutilisation de l'état de vérification dans un contexte différent.
Le CAPTCHA n'est pas un écran autonome — c'est l'une des actions du pipeline de décision TR7. La protection DDoS, la protection bot, la réputation IP et les politiques de prévention de prise de contrôle de compte peuvent toutes déclencher l'action showCaptcha. Chaque module de sécurité peut connecter son propre signal de risque au flux de vérification CAPTCHA. L'opérateur utilise une infrastructure de challenge auto-hébergée unique dans différents scénarios de risque.
Le CAPTCHA auto-hébergé est exploité conjointement avec des processus helper, la gestion des secrets, la liaison de tokens, une machine d'états de quarantaine, le support multilingue et des enregistrements d'audit.
Chaque règle CAPTCHA peut s'exécuter avec un processus helper dédié. Si le processus se termine de façon inattendue, il peut être redémarré automatiquement. Une défaillance dans une règle n'affecte pas la vérification CAPTCHA dans les autres services.
Un chemin de socket dédié peut être créé pour chaque pool et règle CAPTCHA. Cette structure sépare le trafic de vérification des challenges entre les services. Lorsque la configuration est rejouée, le mappage entre la même règle logique et la même structure de socket physique est préservé.
Un secret distinct peut être généré pour chaque règle, et les tokens de vérification sont signés contre ce secret. Lors de la rotation d'un secret, les tokens vérifiés existants peuvent être invalidés. Ce comportement peut être exploité pour des renouvellements de sécurité planifiés.
La résolution PoW peut utiliser des API plus efficaces dans les navigateurs modernes. Dans les environnements sans support, un fallback JavaScript plus lent mais compatible est appliqué. Sur les clients mobiles, le processus de résolution s'exécute de manière asynchrone pour que l'interface utilisateur ne se fige pas.
Les réponses de challenge échouées sont suivies séparément. Lorsque le seuil est dépassé, le client est dirigé vers une action de quarantaine pendant une période configurée. Pendant cette période, deny, redirect ou contenu personnalisé est appliqué directement au lieu de présenter un autre CAPTCHA.
Pour chaque challenge, l'horodatage, l'IP source, le user agent, l'ID de règle, le niveau de difficulté, le type de challenge et le résultat peuvent être journalisés. Le temps de résolution PoW produit également un signal précieux pour l'investigation des incidents. Ces enregistrements soutiennent les workflows d'analyse bot et de forensique de fraude.
Les banques peuvent être tenues d'éviter de transmettre l'IP utilisateur ou les informations du navigateur à des services externes lors de la vérification CAPTCHA. Avec TR7 CAPTCHA Auto-hébergé, le processus de challenge reste à l'intérieur de l'ADC et la protection de connexion est exploitée conformément aux exigences de résidence des données.
Les organismes gouvernementaux opérant dans des environnements sans accès aux services de vérification externes peuvent quand même appliquer la protection bot. La génération et la vérification CAPTCHA TR7 fonctionnent sans nécessiter de résolution DNS externe ni d'appels HTTP sortants.
Pour la fraude aux coupons, la création de faux comptes ou les attaques d'inscription automatisée, l'endpoint d'inscription peut être placé derrière le CAPTCHA selon le score bot. Les tentatives échouées sont liées à la quarantaine, empêchant les bots de consommer continuellement des challenges.
Les portails de santé peuvent vérifier les utilisateurs sur les flux de prise de rendez-vous ou d'accès aux dossiers patients impliquant des données sensibles sans recourir à un service CAPTCHA externe. Le processus de vérification des utilisateurs reste sous contrôle organisationnel.
Lors d'une vague DDoS ou de bots, TR7 peut appliquer le CAPTCHA ou le PoW invisible uniquement aux clients ayant un score de risque élevé. La majorité des utilisateurs réels continue sans friction supplémentaire tandis que le coût pour les bots est augmenté.
Les fournisseurs SaaS B2B peuvent configurer les paramètres de couleur, thème et taille séparément pour chaque tenant. L'écran CAPTCHA ne porte aucun logo tiers et apparaît plus proche de l'expérience utilisateur propre au client.
CAPTCHA auto-hébergé qui maintient les données locales — intégré avec les flux WAAP, DDoS et ATO. Parcourons ensemble une configuration en direct dans votre propre environnement.