Cuando un usuario es bloqueado, el genérico mensaje de "access denied" que ve no es solo una salida técnica; es parte de la experiencia de seguridad de la organización. El cliente corporativo, el ciudadano, el socio de negocio o el usuario final quiere entender por qué se le hace esperar, qué debe hacer y si esto es temporal o permanente. Las páginas de error toscas y sin marca convierten la decisión de seguridad en una experiencia poco profesional.
Durante un ataque DDoS o de bots, mostrar solo un error al usuario a menudo no es suficiente. Al usuario real hay que explicarle que espere un momento, que su solicitud está siendo validada, que el tráfico automatizado está siendo separado y que la operación continuará. La cuenta atrás, el challenge y el flujo CAPTCHA cumplen aquí tanto una función de seguridad como de comunicación.
En entornos multilingües y multi-tenant, la misma página no es adecuada para todos. Un banco puede querer mostrar una explicación en su idioma local y con sus colores corporativos; un proveedor de servicios puede querer usar un logo y un texto distintos para cada tenant; y un endpoint de API debe devolver un mensaje de error JSON en lugar de HTML. Una única página de bloqueo fija no puede cubrir estas necesidades.
Para los equipos de mesa de ayuda y seguridad, el código de motivo también es importante. Cuando un usuario recibe un error, el equipo de soporte debe poder entender qué regla, qué decisión de bot o qué acción WAAP entró en juego. Pero esta información debe darse de forma controlada; en algunos casos se muestra al usuario, en otros se mantiene solo en el log y el flujo de soporte.
El enfoque de TR7 saca a las páginas de bloqueo de ser una salida de error estática que se devuelve tras la decisión de seguridad; las convierte en una experiencia WAAP personalizable con marca, idioma, código de motivo, CAPTCHA, challenge DDoS y formatos de respuesta de API.
TR7 gestiona las páginas de bloqueo con plantillas listas, render EJS, respuesta nativa e inyección de código de motivo.
Hay estructuras de plantilla separadas para challenge DDoS, validación JavaScript, CAPTCHA, error de protección de bots y AAM 503. Cada tipo de página puede diseñarse según una experiencia de usuario y una decisión de seguridad distintas.
Las páginas CAPTCHA se crean con plantillas EJS. El tema, el tamaño, el fondo, el color de texto y el diccionario de idioma pueden aplicarse durante el render.
TR7 puede devolver la respuesta de bloqueo o challenge sin ir al servicio backend. Este enfoque reduce la latencia y a la vez evita que se cargue innecesariamente la capa de aplicación en el momento del ataque.
El reason code y las variables de request personalizadas pueden colocarse de forma controlada dentro de la plantilla. Esto ayuda a los equipos de soporte a aislar el motivo del error y, cuando sea necesario, a dar una explicación significativa al usuario.
La Personalización de Página de Bloqueo de TR7 gestiona de forma centralizada las respuestas HTML, CAPTCHA, challenge y JSON para distintas decisiones WAAP.
TR7 puede usar páginas de challenge especiales para escenarios DDoS. Estas páginas pueden incluir cuenta atrás, información al usuario y mensajes de validación. Al usuario real se le explica que su solicitud está siendo procesada y que continuará en breve. Así, en el momento del ataque se ofrece no solo un bloqueo, sino una experiencia de usuario gestionable.
Las páginas de DDoS JS solver soportan el flujo de validación a través del comportamiento del navegador. Con lógica de control del lado del cliente se busca separar el tráfico automatizado. Pueden usarse archivos listos en múltiples idiomas. La necesidad de un nuevo idioma o un texto distinto se cubre con la estructura de la plantilla.
Las plantillas CAPTCHA crean la experiencia CAPTCHA. Pueden usarse las opciones de tema `auto`, `dark` y `light`; y los tamaños `small`, `medium` y `large`. El color de fondo y de texto puede ajustarse con parámetros. Esta estructura hace que la validación de seguridad sea acorde con la identidad visual de la organización.
En la configuración del CAPTCHA pueden usarse tipos de texto o invisibles. El CAPTCHA de texto es adecuado para situaciones que requieren que el usuario responda de forma explícita. El modo invisible, en cambio, puede preferirse en escenarios donde se desea menor fricción. Así, el mismo control de seguridad se ajusta según distintos objetivos de experiencia de usuario.
TR7 viene con diccionarios de texto CAPTCHA listos en varios idiomas. Alrededor de 16 campos de texto como título, descripción, campo de entrada, enviar, refrescar, validando, exitoso, fallido, error y caducado pueden gestionarse por idioma. Pueden añadirse nuevos idiomas ampliando el objeto de traducción dentro de la plantilla. El usuario puede añadir él mismo el idioma que desee; la estructura multilingüe se proporciona de esta forma.
Cada vService puede usar una apariencia y comportamiento distintos con su propio valor de configuración CAPTCHA. Esto es importante en aplicaciones multi-tenant, MSSP o que operan bajo distintas marcas. En el mismo TR7, cada aplicación puede funcionar con su propio color, idioma, texto y estilo de validación. El control de seguridad permanece centralizado mientras la experiencia de usuario se separa.
Para las decisiones de protección de bots puede usarse una página de error especial. Cuando se desencadena un mal user agent, un comportamiento de automatización o una regla de protección de bots, puede devolverse una respuesta distinta al usuario. Esta página puede personalizarse según el lenguaje de marca y el proceso de soporte. El código de motivo técnico puede mantenerse dentro si se desea, o mostrarse de forma controlada si se desea.
Cuando el servicio backend es inaccesible o el pool no puede prestar servicio temporalmente, puede usarse una página AAM 503 especial. Esta página evita que el usuario vea un error de navegador en blanco o una interrupción de conexión sin sentido. El mantenimiento programado, la sobrecarga temporal o un problema de acceso al servicio pueden presentarse con un mensaje más comprensible. La organización mantiene la marca y la orientación de soporte incluso en el momento del error.
TR7 puede devolver una respuesta personalizada en las acciones WAAP con un status code, content type y contenido de archivo específicos. Puede usarse una página HTML, texto plano o un cuerpo de error JSON para endpoints de API. Puede aplicarse un modelo de devolución de contenido basado en archivo o inline. Esta flexibilidad crea una experiencia de bloqueo distinta para los usuarios web y los clientes de API.
En el contenido de la página pueden colocarse variables de request o códigos de motivo a nivel de transaction. La mesa de ayuda puede entender más rápido qué decisión de seguridad entró en juego a partir de la captura de pantalla o el código de error que envía el usuario. El equipo de seguridad puede determinar como política qué información se muestra al usuario y cuál permanece solo en el lado del log. Esta estructura aumenta la velocidad de depuración mientras mantiene bajo control el riesgo de fuga de información.
Para el funcionamiento fiable de las páginas de bloqueo, se planifican conjuntamente el servicio de archivos, la incorporación de idiomas, la selección de status code, las variables dinámicas y la gestión de assets estáticos.
Para añadir un nuevo idioma a la plantilla CAPTCHA, puede definirse un nuevo diccionario de idioma en el objeto de traducción correspondiente. Los textos de título, error, validación y espera se separan por idioma. Este enfoque vincula el soporte multilingüe no a una lista de productos fija, sino a una estructura de plantilla ampliable.
Para las páginas CAPTCHA y challenge, el base path, la ruta de servicio JavaScript, el archivo HTML y el archivo JavaScript pueden gestionarse con campos de configuración separados. Esta separación garantiza que los contenidos estáticos se sirvan desde la ruta correcta. En múltiples tipos de página, la organización de archivos se mantiene más legible.
TR7, cuando se da una condición específica, puede generar una respuesta HTML o JSON directa con la lógica de respuesta nativa. Esta respuesta se genera sin ir al servicio backend. En challenge, CAPTCHA y acciones WAAP personalizadas, la latencia y la carga de la aplicación se reducen de esta forma.
Para distintos escenarios pueden usarse distintos valores de HTTP status code. Mientras el flujo CAPTCHA puede ofrecerse con 200, las decisiones de límite o bloqueo pueden devolverse con códigos como 403, 413, 451 o 503. Elegir el código semánticamente correcto para los usuarios de API y web aumenta la calidad de la integración.
El logo, el SVG o los contenidos visuales pueden colocarse dentro del HTML de forma inline o como base64. Este método puede reducir la dependencia de assets separados y facilita producir una página personalizada de un solo archivo. La marca de la organización puede añadirse a la página a través de una disposición HTML personalizada.
Los archivos listos de challenge DDoS y validación JS pueden rastrearse con un mecanismo de vinculación dinámica de archivos. Cuando se actualiza un archivo, el contenido correspondiente se refleja en la capa de servicio. Esta estructura ayuda a mantener actualizadas las páginas estáticas sin convertirlo en una operación de reinicio manual del servicio.
El banco puede usar una página CAPTCHA o de bloqueo personalizada con tema blanco/azul, logo corporativo, explicación en su idioma local y enlace de soporte. Mientras el código de motivo se oculta al usuario, el equipo de soporte puede investigar el motivo real a través del log.
Cuando el tráfico de automatización aumenta en periodo de campaña, puede mostrarse al usuario real una página de challenge DDoS con cuenta atrás. El usuario continúa con el flujo de compra tras una breve validación mientras se separa el tráfico de bots.
Una entidad del sector público puede devolver una página personalizada con explicación en el idioma local en determinadas decisiones de acceso. Al usuario se le explica con lenguaje corporativo por qué se restringió el acceso y a qué canal de soporte debe acudir.
En servicios de API es más correcto devolver una respuesta 403 o 429 en formato JSON en lugar de una página HTML. TR7, con una acción WAAP personalizada, inserta el valor reason en el cuerpo JSON para que las aplicaciones cliente puedan procesar el error de forma programática.
Páginas de bloqueo personalizables para DDoS, CAPTCHA, protección de bots y acciones WAAP. Veamos juntos cómo funciona en su propia configuración.