Le message générique « access denied » qu'un utilisateur voit lorsqu'il est bloqué n'est pas qu'une sortie technique ; il fait partie de l'expérience de sécurité de l'organisation. Un client d'entreprise, un citoyen, un partenaire ou un utilisateur final veut comprendre pourquoi il est retenu, ce qu'il doit faire et si c'est temporaire ou permanent. Des pages d'erreur brutes et sans marque transforment la décision de sécurité en une expérience peu professionnelle.
Lors d'une attaque DDoS ou de bots, montrer seulement une erreur à l'utilisateur ne suffit souvent pas. Il faut expliquer au véritable utilisateur d'attendre un court instant, que sa requête est en cours de vérification, que le trafic automatisé est en train d'être distingué et que l'opération va se poursuivre. Le flux de compte à rebours, de challenge et de CAPTCHA remplit alors un rôle à la fois de sécurité et de communication.
Dans les environnements multilingues et multi-tenant, la même page ne convient pas à tout le monde. Une banque peut vouloir afficher une explication avec ses couleurs d'entreprise ; un fournisseur de services peut vouloir utiliser un logo et un texte différents pour chaque tenant ; un endpoint API doit renvoyer un message d'erreur JSON plutôt que du HTML. Une page de blocage unique et fixe ne peut pas répondre à ces besoins.
Pour le help desk et les équipes sécurité, le code de raison est aussi important. Lorsqu'un utilisateur reçoit une erreur, l'équipe de support doit pouvoir comprendre quelle règle, quelle décision de bot ou quelle action WAAP est intervenue. Mais cette information doit être fournie de manière contrôlée ; dans certains cas elle est montrée à l'utilisateur, dans d'autres elle reste uniquement dans le log et le flux de support.
L'approche de TR7 fait sortir les pages de blocage de leur statut de sortie d'erreur statique renvoyée après une décision de sécurité ; elle les transforme en une expérience WAAP personnalisable avec la marque, la langue, le code de raison, le CAPTCHA, le challenge DDoS et les formats de réponse API.
TR7 gère les pages de blocage avec des templates prêts à l'emploi, le rendu EJS, la réponse native et l'injection de code de raison.
Des structures de templates distinctes existent pour le challenge DDoS, la vérification JavaScript, le CAPTCHA, l'erreur de protection contre les bots et l'AAM 503. Chaque type de page peut être conçu selon une expérience utilisateur et une décision de sécurité différentes.
Les pages CAPTCHA sont créées avec des templates EJS. Le thème, la taille, le fond, la couleur du texte et le dictionnaire de langue peuvent être appliqués au moment du rendu.
TR7 peut renvoyer la réponse de blocage ou de challenge sans aller jusqu'au backend. Cette approche réduit à la fois la latence et empêche qu'une charge inutile pèse sur la couche applicative au moment de l'attaque.
Le reason code et des variables de requête personnalisées peuvent être placés de manière contrôlée dans le template. Cela aide les équipes de support à isoler la cause de l'erreur et, le cas échéant, à fournir une explication pertinente à l'utilisateur.
La personnalisation des pages de blocage de TR7 gère de manière centralisée les réponses HTML, CAPTCHA, challenge et JSON pour différentes décisions WAAP.
TR7 peut utiliser des pages de challenge dédiées pour les scénarios DDoS. Ces pages peuvent contenir un compte à rebours, une information à l'utilisateur et des messages de vérification. Il est expliqué au véritable utilisateur que sa requête est traitée et qu'elle se poursuivra peu après. Ainsi, au moment de l'attaque, on assure non seulement un blocage mais une expérience utilisateur gérable.
Les pages DDoS JS solver soutiennent le flux de vérification via le comportement du navigateur. Avec une logique de contrôle côté client, on vise à distinguer le trafic automatisé. Des fichiers prêts à l'emploi en TR et EN peuvent être utilisés. Le besoin d'une nouvelle langue ou d'un texte différent peut être satisfait via la structure de template.
Les templates CAPTCHA créent l'expérience CAPTCHA. Les options de thème `auto`, `dark` et `light` ; les tailles `small`, `medium` et `large` peuvent être utilisées. Les couleurs de fond et de texte peuvent être réglées par paramètres. Cette structure rend la vérification de sécurité cohérente avec l'identité visuelle de l'organisation.
Dans la configuration CAPTCHA, les types texte ou invisible peuvent être utilisés. Le CAPTCHA texte convient aux cas nécessitant que l'utilisateur réponde explicitement. Le mode invisible peut être préféré dans les scénarios où l'on souhaite moins de friction. Ainsi, le même contrôle de sécurité est réglé selon différents objectifs d'expérience utilisateur.
TR7 est livré avec des dictionnaires de texte CAPTCHA prêts à l'emploi en TR et EN. Environ 16 champs de texte tels que titre, description, champ de saisie, envoyer, rafraîchir, en cours de vérification, réussi, échoué, erreur et expiré peuvent être gérés par langue. De nouvelles langues peuvent être ajoutées en les insérant dans l'objet de traduction du template. L'utilisateur peut ajouter lui-même la langue souhaitée ; la structure multilingue est ainsi assurée.
Chaque vService peut utiliser une apparence et un comportement différents avec sa propre valeur de configuration CAPTCHA. C'est important dans les applications multi-tenant, MSSP ou opérant sous différentes marques. Sur le même TR7, chaque application peut fonctionner avec sa propre couleur, langue, texte et style de vérification. Le contrôle de sécurité reste centralisé tandis que l'expérience utilisateur est séparée.
Une page d'erreur dédiée peut être utilisée pour les décisions de protection contre les bots. Lorsqu'un mauvais user agent, un comportement d'automatisation ou une règle de protection contre les bots est déclenché, une réponse distincte peut être renvoyée à l'utilisateur. Cette page peut être personnalisée selon le langage de marque et le processus de support. Le code de raison technique peut être conservé en interne si souhaité, ou montré de manière contrôlée.
Lorsque le backend est inaccessible ou que le pool ne peut temporairement plus servir, une page AAM 503 dédiée peut être utilisée. Cette page empêche l'utilisateur de voir une erreur de navigateur vide ou une interruption de connexion inexpliquée. Une maintenance planifiée, une surcharge temporaire ou un problème d'accès au service peut être présenté avec un message plus compréhensible. L'organisation préserve sa marque et son orientation de support même au moment de l'erreur.
TR7 peut renvoyer une réponse personnalisée dans les actions WAAP avec un status code, un content type et un contenu de fichier spécifiques. Une page HTML, du texte brut ou un body d'erreur JSON pour les endpoints API peuvent être utilisés. Un modèle de retour de contenu basé sur fichier ou inline peut être appliqué. Cette flexibilité crée une expérience de blocage différente pour les utilisateurs web et les clients API.
Des variables de requête ou des codes de raison au niveau de la transaction peuvent être placés dans le contenu de la page. Le help desk peut comprendre plus vite, à partir d'une capture d'écran ou d'un code d'erreur fourni par l'utilisateur, quelle décision de sécurité est intervenue. L'équipe sécurité peut déterminer par politique quelles informations seront montrées à l'utilisateur et lesquelles resteront uniquement côté log. Cette structure augmente la rapidité de débogage tout en gardant sous contrôle le risque de fuite d'information.
Pour un fonctionnement fiable des pages de blocage, la diffusion des fichiers, l'ajout de langue, le choix du status code, les variables dynamiques et la gestion des assets statiques sont planifiés ensemble.
Pour ajouter une nouvelle langue au template CAPTCHA, un nouveau dictionnaire de langue peut être défini dans l'objet de traduction concerné. Les textes de titre, d'erreur, de vérification et d'attente sont séparés par langue. Cette approche relie le support multilingue non pas à une liste de produit fixe, mais à une structure de template extensible.
Pour les pages CAPTCHA et challenge, le base path, le chemin de service JavaScript, le fichier HTML et le fichier JavaScript peuvent être gérés via des champs de configuration distincts. Cette séparation garantit que les contenus statiques sont servis depuis le bon chemin. Dans les types de pages multiples, l'organisation des fichiers reste plus lisible.
Lorsqu'une condition donnée se produit, TR7 peut produire directement une réponse HTML ou JSON avec une logique de réponse native. Cette réponse est produite sans aller jusqu'au backend. Pour le challenge, le CAPTCHA et les actions WAAP personnalisées, la latence et la charge applicative sont ainsi réduites.
Différentes valeurs de status code HTTP peuvent être utilisées pour différents scénarios. Tandis que le flux CAPTCHA peut être servi avec un 200, les décisions de limite ou de blocage peuvent être renvoyées avec des codes comme 403, 413, 451 ou 503. Choisir le bon code sémantique pour les utilisateurs API et web améliore la qualité d'intégration.
Un logo, un SVG ou des contenus visuels peuvent être placés dans le HTML en inline ou en base64. Cette méthode peut réduire la dépendance à des assets séparés et facilite la production d'une page personnalisée en un seul fichier. La marque de l'organisation peut être ajoutée à la page via une mise en page HTML personnalisée.
Les fichiers prêts à l'emploi de challenge DDoS et de vérification JS peuvent être suivis via un mécanisme de liaison dynamique de fichiers. Lorsqu'un fichier est mis à jour, le contenu concerné est répercuté sur la couche de service. Cette structure aide à maintenir les pages statiques à jour sans les transformer en une opération de redémarrage manuel du service.
Une banque peut utiliser une page CAPTCHA ou de blocage personnalisée avec un thème blanc/bleu, son logo d'entreprise, une explication et un lien de support. Le code de raison est masqué à l'utilisateur tandis que l'équipe de support peut examiner la véritable cause via le log.
Lorsque le trafic d'automatisation augmente en période de campagne, une page de challenge DDoS avec compte à rebours peut être montrée au véritable utilisateur. L'utilisateur poursuit son parcours d'achat après une courte vérification tandis que le trafic de bots est distingué.
Un organisme public peut renvoyer une page personnalisée avec une explication dans la langue locale pour certaines décisions d'accès. Il est expliqué à l'utilisateur, dans un langage institutionnel, pourquoi l'accès est restreint et à quel canal de support s'adresser.
Pour les services API, renvoyer une réponse 403 ou 429 au format JSON plutôt qu'une page HTML est plus approprié. Avec une action WAAP personnalisée, TR7 insère la valeur reason dans le body JSON pour permettre aux applications clientes de traiter l'erreur de manière programmatique.
Pages de blocage personnalisables pour le DDoS, le CAPTCHA, la protection contre les bots et les actions WAAP. Voyons ensemble comment cela fonctionne dans votre propre configuration.