Las páginas web modernas no están construidas exclusivamente con el JavaScript propio de la organización. Las páginas de pago, las herramientas de analítica, los widgets de chat, los sistemas de pruebas A/B, las etiquetas publicitarias y los SDK de pago pueden cargar múltiples scripts de terceros. Si alguno de esos scripts se ve comprometido, el código malicioso que se ejecuta en el navegador del usuario puede eludir completamente los controles clásicos a nivel de solicitud del WAAP.
En los flujos de pago en particular, el riesgo del lado del cliente ya no es solo una cuestión de buenas prácticas. PCI DSS 4.0 v4.0.1 ha hecho más visible el control, el inventario y la integridad de los scripts que se ejecutan en las páginas de pago. Las organizaciones deben ser capaces de demostrar qué fuentes están autorizadas a ejecutarse en qué páginas.
Pedir a los equipos de desarrollo que añadan manualmente cabeceras CSP, HSTS, protección contra marcos y política de referrer en cada página no es sostenible. Los cambios de código son difíciles en aplicaciones heredadas; en aplicaciones modernas, distintos equipos de servicio pueden no aplicar el mismo estándar de seguridad de forma coherente. El resultado son cabeceras de seguridad presentes en algunas páginas y ausentes en otras.
El enfoque correcto es aplicar las cabeceras de seguridad del navegador de forma centralizada, independientemente del código de la aplicación y desde una posición basada en políticas. El ADC debe reescribir las cabeceras de respuesta para estandarizar CSP, HSTS, protección contra clickjacking, prevención de MIME sniffing, control de referrer y limpieza del fingerprint.
TR7 Protección de Scripts del Lado del Cliente ofrece este modelo: aplica cabeceras de seguridad fundamentales para el riesgo del lado del cliente a nivel de vService y vincula la seguridad del navegador con la política central WAAP.
TR7 implementa la protección de scripts del lado del cliente mediante la reescritura de cabeceras de respuesta, un perfil CSP, la limpieza del fingerprint y visibilidad de cumplimiento.
TR7 aplica cabeceras de seguridad durante la fase de respuesta HTTP utilizando el comportamiento set-header o add-header. Los controles de seguridad del navegador pueden activarse sin cambiar el código de la aplicación ni la estructura de certificados.
La cabecera Content-Security-Policy comunica al navegador el modelo de origen permitido. TR7 proporciona actualmente protección CSP de base mediante un enfoque fijo de `default-src 'self';`.
Cabeceras como Server, X-Powered-By, X-AspNet-Version y X-AspNetMvc-Version pueden eliminarse de las respuestas. Esto dificulta que los atacantes construyan un inventario tecnológico y correlacionen CVEs.
Los vServices con una regla securityHeaders activa pueden mostrarse como evidencia en los informes de cumplimiento. Esto refuerza el rastro de auditoría para los procesos de seguridad de páginas de pago y controles del lado del cliente.
La Protección de Scripts del Lado del Cliente aplica 8 cabeceras de seguridad prefabricadas bajo una única regla securityHeaders.
TR7 puede añadir la cabecera Content-Security-Policy a través de la regla securityHeaders. El comportamiento actual produce una política de seguridad de base con `default-src 'self';`. Esta política tiene como objetivo un comportamiento predeterminado del navegador que solo acepta recursos del mismo origen. Los requisitos CSP más complejos deben abordarse mediante configuración de cabecera personalizada o cambios en el lado de la aplicación.
La cabecera Strict-Transport-Security puede aplicarse en conexiones TLS. Indica al navegador que exija HTTPS para el dominio correspondiente. Las opciones como includeSubDomains y preload proporcionan un comportamiento de seguridad más estricto. HSTS solo se aplica en el contexto TLS para evitar que se emita una política incorrecta a hosts solo-HTTP.
La cabecera X-Frame-Options puede aplicarse con el valor SAMEORIGIN. Esto restringe que la página se cargue dentro de un iframe en un origen diferente. Ayuda a reducir el riesgo de clickjacking especialmente en páginas de inicio de sesión, pago, panel de administración y transacciones sensibles. Proporciona protección de base de bajo coste contra ataques de redirección de interfaz de usuario.
La cabecera X-Content-Type-Options puede añadirse con el valor nosniff. Esto ayuda a evitar que el navegador adivine un tipo de contenido y ejecute contenido en un formato inesperado. El control es especialmente valioso para flujos de carga de archivos, contenido estático y aplicaciones heredadas que devuelven tipos de contenido incorrectos. Se reduce el riesgo del lado del cliente derivado de la confusión de MIME.
La cabecera Referrer-Policy puede aplicarse con el valor predeterminado no-referrer-when-downgrade. Esto limita la filtración del referrer en escenarios como las transiciones de HTTPS a HTTP. El comportamiento del referrer importa en las URL que contienen parámetros de ciudadano, cliente o sesión. Las organizaciones pueden limitar de forma centralizada cuánta información de URL de origen lleva el navegador a sitios externos.
La cabecera Permission-Policy puede utilizarse para restringir el acceso a capacidades del navegador como el micrófono, la cámara, la geolocalización y APIs similares. TR7 aplica esta cabecera bajo la regla securityHeaders para reducir la superficie innecesaria de permisos del navegador. En portales, páginas de pago y pantallas de administración en particular, esto evita que las páginas accedan a APIs inesperadas. La seguridad del lado del cliente no se limita únicamente al origen de los scripts.
Aunque la cabecera X-XSS-Protection tiene un efecto limitado en los navegadores modernos, puede utilizarse para compatibilidad con clientes más antiguos. El comportamiento `1; mode=block` activa un filtro XSS básico en algunos navegadores heredados. Esta cabecera no es una garantía de seguridad por sí sola y debe considerarse junto con los controles CSP y WAAP. Proporciona una capa adicional de bajo coste para organizaciones con una base de usuarios heredada.
TR7 puede eliminar cabeceras como Server, X-Powered-By, X-AspNet-Version y X-AspNetMvc-Version. Estas cabeceras pueden revelar información sobre el servidor de aplicaciones, el framework o la versión del runtime en uso. Los atacantes pueden utilizar esta información para correlacionar CVEs y realizar intentos de exploit dirigidos. La limpieza del fingerprint es un paso de fortalecimiento práctico que reduce la superficie de ataque visible.
securityHeaders puede vincularse como tipo de regla a condiciones específicas de vService, dominio o ruta. Una página de pago puede ejecutarse con un conjunto más estricto, un portal interno con uno diferente, y una aplicación heredada con una combinación más permisiva. Esto evita que una única política de cabecera global rompa las aplicaciones. Los operadores aplican las cabeceras de seguridad según el contexto del servicio.
TR7 implementa el alcance actual de la protección de scripts del lado del cliente en la capa de cabeceras de respuesta. No se necesita ningún agente JavaScript adicional, SDK del cliente ni reverse proxy separado. Este enfoque proporciona baja latencia y amplia compatibilidad. La capacidad actual real es la estandarización de cabeceras de seguridad; no se hace ninguna afirmación de detección de skimmers en tiempo de ejecución ni de inyección automática de SRI.
Los vServices con una regla securityHeaders activa pueden mostrarse en los informes de cumplimiento. Esto facilita compartir con los auditores exactamente dónde se aplican las cabeceras de seguridad de las páginas de pago. Apoya la producción de evidencia técnica para las expectativas de seguridad del lado del cliente bajo PCI DSS 4.0 v4.0.1. Los informes hacen visible no solo que una política de cabecera está configurada, sino en qué servicios está activa.
Cuando se devuelven páginas HTML personalizadas — como para la protección anti-bots o el bloqueo de acceso — las cabeceras de seguridad pueden mantenerse en la misma ruta de respuesta. Esto evita que las páginas de error o desafío devuelvan cabeceras de seguridad más débiles que las de la aplicación principal. Cada respuesta presentada al usuario se aproxima al mismo estándar de seguridad base del navegador. La consistencia es especialmente importante en los flujos de inicio de sesión y verificación de bots.
La protección de scripts del lado del cliente opera en el orden de las cabeceras de respuesta, la condición HSTS, el comportamiento CSP fijo, el tipo de regla securityHeaders y la limpieza del fingerprint.
TR7 puede sobreescribir algunas cabeceras con set-header y añadir otras con add-header. Esta distinción determina cómo se comportan las cabeceras existentes de la aplicación. Antes de pasar a producción, conviene comprobar si las cabeceras propias de la aplicación entran en conflicto con las añadidas por TR7.
HSTS solo debe aplicarse en conexiones TLS. TR7 asocia esta cabecera con la condición ssl_fc para evitar que los hosts solo-HTTP reciban una cabecera HSTS errónea. Una política HSTS incorrecta puede causar problemas de acceso en algunos dominios, por lo que debe usarse con cuidado.
Cuando se habilita CSP en el comportamiento actual de securityHeaders, la cabecera `default-src 'self';` se produce como un valor fijo. No existe ningún editor de directivas personalizado adicional dentro de las capacidades activas de esta página. Para requisitos CSP más detallados, debe planificarse una regla de cabecera personalizada o una configuración en el lado de la aplicación.
securityHeaders no funciona como una regla de puntuación de firmas WAAP. Se trata como una regla de fortalecimiento de cabeceras de respuesta que siempre se aplica. En consecuencia, no está vinculada a una puntuación de ataque ni a un resultado de umbral.
Las cabeceras Server, X-Powered-By, X-AspNet-Version y X-AspNetMvc-Version pueden eliminarse. Eliminar estas cabeceras no cambia el comportamiento de la aplicación; solo reduce la visibilidad de la información tecnológica hacia el exterior. En aplicaciones heredadas, este simple paso puede reducir significativamente la filtración de información.
Las políticas CSP y de marcos pueden afectar a algunos componentes de la aplicación. Las páginas que utilizan scripts inline o cargan contenido desde fuentes externas en particular deben validarse primero en un entorno de prueba. El enfoque basado en reglas de TR7 facilita probar una política estricta en una ruta o dominio limitado antes de desplegarla ampliamente.
Los equipos de e-commerce pueden habilitar CSP, HSTS y la limpieza del fingerprint del servidor a nivel de vService en las páginas de checkout. Esta configuración genera evidencia técnica reportable para los controles de seguridad del lado del cliente de PCI DSS 4.0 v4.0.1.
Los portales bancarios pueden usar X-Frame-Options SAMEORIGIN y Permission-Policy para restringir la incrustación de iframes no autorizada y el acceso innecesario a APIs del navegador. Se reduce la superficie de ataque del lado del cliente en páginas de inicio de sesión y transacciones.
Las aplicaciones del sector público pueden aplicar Referrer-Policy en páginas que contienen información URL sensible. Esto reduce el riesgo de que fragmentos de URL vinculados a sesiones de ciudadanos o al contexto de transacciones sean llevados a sitios externos.
En aplicaciones .NET antiguas o similares, las cabeceras Server, X-Powered-By y de versión del framework pueden filtrarse externamente. TR7 elimina estas cabeceras, dificultando que los atacantes construyan un inventario tecnológico.
Los proveedores SaaS pueden aplicar distintas combinaciones de securityHeaders para cada vService de tenant. Los tenants B2B pueden ejecutar una política más permisiva donde los requisitos de cumplimiento lo permitan; los flujos B2C pueden usar un conjunto de cabeceras más estricto.
CSP, HSTS, protección contra clickjacking y limpieza del fingerprint del servidor — desde una única política, sin modificar el código de la aplicación. Permítanos guiarle en una configuración en vivo con sus propios servicios.