PCI DSS 4.0 ya está aquí. A partir de marzo de 2025, exige que los portales de pago cuenten con un mecanismo para autorizar cada script en las páginas de pago. Los sitios web deben mantener un inventario de todos los scripts (al menos en esos portales de pago) y garantizar su integridad. Ahora es necesario detectar y responder a modificaciones no autorizadas en las páginas de pago, incluidos cambios en las cabeceras HTTP y el contenido de las páginas. Las organizaciones deben verificar estas configuraciones al menos una vez cada siete días o según lo determine su evaluación de análisis de riesgos.
Lee los requisitos completos aquí.
Otro punto importante es que PCI DSS 4.0 promueve ahora un cambio de las auditorías anuales hacia la monitorización continua de la seguridad, lo que implica revisiones y actualizaciones periódicas de los componentes del sistema y del software.
¡Por fin!
Por el momento, solo los portales de pago están obligados a contar con un sistema para controlar el JavaScript de terceros. Por eso, muchos de nuestros competidores (lee lo que pensamos sobre ellos aquí) limitan sus servicios a unas pocas páginas. Algunos incluso muestrean la sesión, de modo que solo el 10 % de las sesiones están protegidas.
Pero eso es buscar problemas.
Por qué deberías proteger todas las páginas
Sigue existiendo riesgo de brecha de datos si no aseguras todas las páginas.
Los actores maliciosos podrían usar scripts comprometidos en otras partes de tu sitio para secuestrar sesiones de usuario. Esto les permitiría suplantar a usuarios legítimos y realizar acciones no autorizadas, pudiendo incluso eludir algunas formas de autenticación de dos factores. Eso podría sortear la protección de scripts de terceros en los portales de pago.
Otra área que dejarías expuesta al riesgo son las vulnerabilidades de Cross-site scripting (XSS). Permiten a los atacantes inyectar scripts maliciosos en páginas web vistas por otros usuarios. Si solo el portal de pago está protegido, otras páginas podrían ser explotadas para ejecutar ataques XSS, afectando igualmente los datos y la privacidad de los usuarios.
Incluso en algunos casos, los ataques a la cadena de suministro no quedan completamente bloqueados. Los scripts de terceros son un vector habitual para este tipo de ataques. Si los atacantes comprometen un proveedor o un script utilizado en todo tu sitio, concentrar las protecciones solo en el portal de pago no impedirá la explotación a través de otras integraciones de terceros.
Las vulnerabilidades de Ejecución Remota de Código (RCE) e Inyección de Comandos representan riesgos de seguridad significativos que refuerzan aún más la necesidad de proteger todas las páginas, no solo las áreas críticas como los portales de pago. RCE permite a los atacantes ejecutar código arbitrario en tu servidor, lo que puede derivar en un compromiso total del sistema. Esto puede ocurrir mediante el manejo inseguro de entradas de usuario, como la evaluación de código subido por usuarios o inyectado a través de campos de formulario.
Las vulnerabilidades de Inyección de Comandos surgen cuando entradas de usuario no seguras se ejecutan como comandos del sistema, especialmente a través de entradas JavaScript incorrectamente saneadas. Esto puede permitir a los atacantes manipular acciones del servidor o acceder a bases de datos del backend, lo que lleva a cambios no autorizados en los datos o a su robo.
Por último, la ingeniería social y el phishing son una amenaza real. Los atacantes podrían modificar contenido o redirigir a los usuarios a sitios maliciosos, engañándolos para que proporcionen información sensible.
Otras vulnerabilidades
Aunque tus portales de pago estén protegidos y la protección funcione, como hemos visto, sigues corriendo el riesgo de que los scripts de otras páginas sean vulnerados.
Si eso ocurre, te arriesgas a perder la confianza de los usuarios y a enfrentar posibles implicaciones legales o regulatorias, especialmente en relación con leyes de protección de datos como el RGPD o la CCPA. Los daños derivados de las sanciones económicas o el daño reputacional son difíciles de cuantificar. Sin embargo, están ahí.
Hazlo bien desde el principio
Al igual que las reglas de PCI DSS 4.0, también animamos a cualquier propietario de sitio web a adoptar la monitorización continua de la seguridad. Y espero haber dejado claro que hacerlo en todas las páginas es la mejor opción.
El nivel gratuito de cside hace que tu sitio cumpla con PCI DSS en lo relativo a scripts de terceros, y funciona en todas las páginas. Sin embargo, nuestro enfoque es diferente al de la competencia. Nuestro script reescribe las fuentes de otros scripts de tu sitio para enrutarlos a través de cside y realizar algunas detecciones en el lado del navegador. Esto hace que cside se sitúe en el flujo de la solicitud entre el usuario y el script de terceros sin añadir latencia, e incluso mejora el rendimiento en algunos casos mediante el almacenamiento en caché de scripts estáticos.
Esto permite una visibilidad total de los scripts servidos, en el 100 % de las sesiones y en todas las páginas. Protegiéndote tanto a ti como a tus usuarios.
Si quieres saber más sobre cómo nuestro enfoque se diferencia del resto, visita esta página.
