PCI DSS

PCI Shield de cside usa controles de client-side security y client-side protection para proteger páginas de pago frente a Magecart, e-skimming, formjacking y otros ataques que se ejecutan en el navegador del cliente. Esta página explica cómo cside se alinea con los Requisitos 6.4.3 y 11.6.1 de PCI DSS y cómo configurar evidencia lista para auditoría.

¿Qué es PCI DSS?

El Payment Card Industry Data Security Standard (PCI DSS) es un conjunto de directrices que garantiza la seguridad de las transacciones con tarjeta a nivel global. Creado por el PCI Security Standards Council, su objetivo es proteger frente al robo de datos y el fraude en las transacciones con tarjetas de débito y crédito.

PCI DSS v4.0.1 introduce dos requisitos que regulan los scripts y las cabeceras entregados al navegador del titular de la tarjeta en las páginas de pago:

• 6.4.3 cubre la autorización, integridad e inventario de los scripts.
• 11.6.1 cubre la detección de cambios y manipulaciones en las cabeceras HTTP con impacto en la seguridad y en el contenido de los scripts de las páginas de pago.

Puedes consultar la especificación completa en el sitio web del PCI Security Standards Council.

Dos modos de despliegue, ambos conformes

cside ofrece dos modos de monitorización. Ambos cumplen los requisitos 6.4.3 y 11.6.1. Elige el que se ajuste a tu nivel de riesgo y a tu capacidad para desplegar cambios de código.

Método de escaneo (sin cambios de código)

• Ejecuta contenedores de navegador completos (no simples fetches HTTP) dos veces al día sobre todo el sitio web y sobre el flujo de usuario que lleva a la página de pago.
• Monitoriza los scripts a medida que el DOM se renderiza por completo, incluyendo sub-peticiones y recursos cargados tarde que los escáneres HTTP básicos pasan por alto.
• Imita el comportamiento de un usuario real para capturar scripts inyectados dinámicamente y activos rotados por CDN.

Dos escaneos diarios superan el requisito “al menos semanalmente” de 11.6.1 y cumplen la expectativa de inventario periódico de 6.4.3.

Método de script (en tiempo real, en línea)

• Se carga en línea en la sesión real del usuario y registra cada script y cada acción de script en tiempo real en la infraestructura de cside.
• Proporciona visibilidad a nivel de petición en el panel de control.
• Permite un bloqueo granular: cside puede bloquear acciones concretas o detener scripts completos.
• Se integra con CSP. cside también impide que scripts maliciosos inyecten directivas CSP para desactivar el propio script de cside, un comportamiento que no hemos observado en ninguna otra solución del mercado.

Requisito 6.4.3

Todos los scripts de las páginas de pago que se cargan y ejecutan en el navegador del consumidor se gestionan del siguiente modo…

”Se implementa un método para confirmar que cada script está autorizado.”

PCI DSS permite modelos de autorización previa y posterior. cside admite ambos:

• Método de escaneo: los scripts detectados en la página de pago y en su flujo de usuario se muestran en el panel de PCI DSS para que un usuario identificado los revise y autorice. El panel y el registro de auditoría indican quién autorizó cada script y cuándo.
• Método de script: además de la autorización desde el panel, cside puede impedir técnicamente la ejecución de scripts no autorizados o de acciones concretas en tiempo real. Funciona junto con CSP y sigue operando aunque un atacante intente inyectar directivas CSP para desactivar cside.

Las decisiones de autorización, la identidad de quien autoriza y las marcas de tiempo se escriben en el registro de auditoría y pueden exportarse para tu QSA.

”Se implementa un método para asegurar la integridad de cada script.”

cside verifica la integridad en varios ejes en lugar de depender de una única comprobación de hash:

• Hashing del payload: se calcula el hash del cuerpo de cada script. Cada nuevo hash dispara todo el pipeline de análisis.
• Pipeline de análisis de contenido: los nuevos payloads se desofuscan, se formatean y se evalúan a través de nuestro motor de reglas propietario en Rust, reglas Yara, un LLM local de contexto reducido, modelos más grandes para un análisis profundo y una etapa de revisión humana por parte del equipo de cside.
• Verificación de metadatos de origen: cada origen de script se contrasta con el histórico del emisor SSL (para detectar intentos de secuestro), el histórico de registro y propiedad del dominio, cambios en los registros DNS y NS, el estado RPKI de las direcciones IP que lo resuelven (para detectar fugas BGP) y DNS inverso para identificar coincidencias de infraestructura con dominios maliciosos conocidos.
• Contexto histórico: cside conserva los hashes anteriores servidos tras la misma URL, de modo que los cambios de integridad entre versiones puedan auditarse. El panel muestra cada variante de hash y renderiza el payload para su inspección.

”Se mantiene un inventario de todos los scripts con una justificación escrita, comercial o técnica, de por qué cada uno es necesario.”

El panel de PCI DSS está diseñado específicamente para esta cláusula:

• Un inventario en tiempo real de cada script detectado en las páginas de pago, incluido el objeto padre que lo cargó.
• Justificaciones comerciales y técnicas generadas por IA a partir del payload y su comportamiento (permitido explícitamente por el PCI SSC), que un usuario revisa y confirma.
• Entradas de auditoría por script que registran quién aceptó o editó cada justificación, con historial de revisiones completo.
• Payloads formateados con las APIs sensibles del navegador resaltadas en línea para que quienes revisan puedan decidir con conocimiento de causa.

Requisito 11.6.1

Se despliega un mecanismo de detección de cambios y manipulaciones…

”Para alertar al personal sobre modificaciones no autorizadas de las cabeceras HTTP con impacto en la seguridad y del contenido de los scripts de las páginas de pago tal y como los recibe el navegador del consumidor.”

cside captura las cabeceras y el contenido de los scripts tal y como llegan a un navegador real, no tal y como los devuelve una petición desde el servidor. Esto es importante porque muchos sitios sirven cabeceras y scripts diferentes en función del User-Agent, la huella TLS, la detección de bots y el enrutamiento geográfico.

Cabeceras con impacto en la seguridad monitorizadas:

• Content Security Policy
• Content Security Policy Report Only
• Report To
• Reporting Endpoints
• Strict Transport Security
• X-Frame-Options
• Cross-Origin Resource Policy
• Cross-Origin Opener Policy
• Cross-Origin Embedder Policy
• Permissions Policy
• X-Content-Type-Options
• X-Permitted-Cross-Domain-Policies
• Referrer Policy
• X-XSS-Protection

cside trata cada cambio de hash como un script nuevo. Cada vez que el payload cambia, el nuevo hash se desofusca automáticamente y pasa por todo el pipeline de detección. Las alertas no se disparan por el cambio en sí, se disparan cuando el análisis detecta algo fuera de lugar.

En concreto:

• Cada cambio de hash se analiza como un script nuevo. Los scripts nuevos, eliminados, los payloads modificados y las desviaciones de comportamiento (nuevos destinos de red, nuevas APIs del DOM, nuevas superficies de almacenamiento accedidas) se capturan y evalúan. La detección no se basa en firmas del script padre.
• Las alertas se disparan ante mal comportamiento. Si una variante de hash se comporta de forma anómala o aparece algo preocupante (orígenes o payloads conocidos como maliciosos, intentos de manipular CSP, comportamiento propio de exfiltración, puntuaciones de amenaza por encima del umbral, patrones de ofuscación novedosos), cside envía una alerta en tiempo real a los endpoints de notificación configurados.
• El inventario rutinario se reporta periódicamente. El informe semanal en PDF (configurable a diario) lista cada script detectado en las páginas de pago, cada URL de página de pago, cada cambio de cabecera de seguridad y cada justificación de negocio con su autor. Esto cumple la cláusula “al menos semanalmente” de 11.6.1.

Esto supera el estándar. 11.6.1 exige evaluación periódica; cside ejecuta análisis por hash de forma continua y añade alertas inmediatas por encima.

”El mecanismo está configurado para evaluar las cabeceras HTTP y las páginas de pago recibidas.”

cside evalúa las cabeceras y el payload tal y como se renderizan en el navegador. Cuando las cabeceras no están normalmente expuestas a un script dentro de la página, cside utiliza el contexto del navegador para obtenerlas. Si tus páginas de pago están tras una VPN o en un entorno cerrado, cside proporciona una IP estática para que el escáner pueda alcanzarlas.

”Las funciones del mecanismo se ejecutan al menos semanalmente, o de forma periódica con la frecuencia definida en el análisis de riesgo dirigido de la entidad (Requisito 12.3.1).”

• El método de escaneo se ejecuta dos veces al día.
• El método de script se ejecuta de forma continua, en la sesión real del usuario.
• Por defecto se envía un informe semanal en PDF con todos los cambios de cabeceras de seguridad, todos los scripts detectados en las páginas de pago, todas las URLs de páginas de pago y todas las justificaciones (incluido quién las redactó). Esta cadencia puede aumentarse a diaria.
• Las detecciones de scripts maliciosos se alertan de inmediato, fuera del informe semanal.

Aprobación por QSA

cside tiene una tasa de aprobación del 100% por parte de QSAs. Trabajamos directamente con grandes bancos, proveedores de pago y firmas de QSA. Hay un whitepaper firmado por VikingCloud disponible en nuestro trust center, y la mayoría de firmas QSA han revisado la solución.

En qué cside va más allá del requisito

PCI DSS marca un suelo, no un techo. Las siguientes capacidades van más allá de la letra de 6.4.3 y 11.6.1:

• Pipeline de detección por capas: reglas Yara, un motor de reglas propietario en Rust, LLMs de contexto reducido, LLMs grandes y revisión humana. La mayoría de competidores dependen solo de feeds de amenazas de terceros.
• Comprobaciones de procedencia del origen: cambios de emisor SSL, histórico de dominio y DNS, validación RPKI y DNS inverso de las IPs que resuelven.
• Resistencia a manipulación de CSP: cside detecta y bloquea los intentos de scripts maliciosos por inyectar directivas CSP que desactivarían el propio script de cside.
• Visibilidad a nivel de petición: cada sub-petición realizada por un script se registra junto con su objeto padre.
• Desofuscación y formateo: el panel muestra la versión legible por humanos de cada payload con las APIs sensibles resaltadas.
• Investigación continua de la web pública: cside investiga sitios que no son clientes para detectar ataques novedosos antes de que lleguen a las páginas de pago de los clientes.

Configurar el panel de PCI DSS

Acceder a la configuración de PCI DSS

Para acceder al panel de PCI DSS, abre el panel y después:

1. Selecciona tu dominio en la barra lateral
2. Selecciona PCI DSS

Añadir páginas de pago

Antes de empezar a usar el panel de PCI DSS debes identificar tus páginas de pago. Esto ayuda a filtrar los datos para centrarse en los scripts y las cabeceras relacionados con el pago.

1. Haz clic en Add a Payment Page o en + Add Payment Page
2. Introduce la URL de la página de pago siguiendo el formato de coincidencia de patrones de script

3. Haz clic en Create

Configuración de página vs modal

Hay dos opciones principales de configuración según tu implementación de pagos:

Configuración de página

Usa esta opción si tus páginas de pago:

• Se renderizan en el servidor (SSR)
• Se cargan mediante recarga o navegación de página
• Están aisladas de los scripts presentes durante la navegación en cliente

Esta configuración filtra la lista de scripts para mostrar solo los presentes en las páginas de pago designadas.

Configuración de modal

Usa esta opción si tus formularios de pago se implementan mediante:

• Ventanas modales
• Widgets emergentes
• Superposiciones de paywall
• Cualquier UI dinámica en la que los pagos puedan procesarse en varias páginas

Esta configuración monitoriza los scripts en toda tu aplicación, ya que los formularios de pago pueden aparecer en cualquier página.

Se configura con un selector CSS que identifica tu modal o formulario de pago.

Ejemplo de selector:

#pay

El panel mostrará todos los scripts que podrían interactuar con el formulario de pago cuando esté activo.

Preguntas frecuentes

¿Qué exigen los Requisitos 6.4.3 y 11.6.1 de PCI DSS?

El Requisito 6.4.3 de PCI DSS exige que los scripts de las páginas de pago estén autorizados, se verifique su integridad, se mantengan en inventario y tengan justificación. El Requisito 11.6.1 exige detección de cambios y manipulaciones en cabeceras HTTP con impacto en seguridad y en el contenido de scripts de páginas de pago tal como lo recibe el navegador del consumidor.

¿Cómo protege la client-side security las páginas de pago?

La client-side security protege páginas de pago monitorizando los scripts que se ejecutan en el navegador, detectando cambios no autorizados y alertando cuando el comportamiento de un script sugiere robo de datos o manipulación. cside aporta visibilidad en runtime para que los equipos vean qué scripts de terceros cargan, qué solicitan y si interactúan con flujos de checkout sensibles.

¿Cómo aborda cside Magecart, e-skimming y formjacking?

cside analiza payloads de scripts, sub-peticiones, metadatos de origen y comportamiento en runtime para detectar señales de Magecart, e-skimming, formjacking y ataques similares basados en navegador. Cuando cside detecta comportamiento malicioso, puede alertar a tu equipo y, en modo script, bloquear el script o acciones concretas.

¿El modo solo escáner es suficiente para PCI DSS?

Sí. El método de escaneo está diseñado para cumplir las expectativas de inventario periódico y detección de cambios de PCI DSS 6.4.3 y 11.6.1. El método de script añade monitorización continua en runtime y bloqueo para equipos que quieren mayor client-side protection por encima del mínimo de cumplimiento.

¿Cómo ayudan los informes de cside a QSAs y a la evidencia de auditoría?

Los informes de cside muestran URLs de páginas de pago, scripts detectados, cambios de cabeceras, decisiones de autorización, justificaciones de negocio, autores y marcas de tiempo. Esto da a los QSAs evidencia de que los scripts de páginas de pago se rastrean y revisan, sin depender de capturas de pantalla u hojas de cálculo manuales.

¿cside aplica controles de scripts o solo monitoriza?

Ambas cosas, según el modo. El método de script puede bloquear scripts y acciones concretas en tiempo real y también bloquea los intentos de inyección de CSP destinados a desactivar el monitor. El método de escaneo es, por diseño, solo de monitorización. PCI DSS permite explícitamente los escáneres de post-autorización, y el PCI SSC lo ha confirmado directamente.

¿Hasta qué punto la detección es en tiempo real?

El método de script se ejecuta en línea en la sesión del usuario y envuelve la mayoría de APIs del navegador para observar cómo los scripts modifican el DOM, por lo que el análisis sucede mientras los scripts se ejecutan. El mismo hash de payload no se analiza dos veces porque no aporta valor de seguridad. 11.6.1 no exige monitorización del 100% de las sesiones; basta con la evaluación periódica, y cside cumple tanto el criterio periódico como el continuo.

¿Cómo gestiona cside los ataques novedosos u ofuscados?

La detección no se basa en firmas del script padre. cside registra cada sub-petición realizada por un script, desofusca los payloads antes de evaluarlos y ejecuta análisis profundo con IA sobre todo lo que cruza el umbral de riesgo. Los payloads novedosos y zero-day son un objetivo de diseño específico. Consulta Detección de amenazas para ver el pipeline de detección completo.

¿Cómo se rastrean las justificaciones de negocio?

El panel de PCI DSS registra cada justificación en la interfaz y en el registro de auditoría, incluido quién la redactó o editó y cuándo. Las justificaciones generadas por IA están explícitamente permitidas por el PCI SSC y se presentan a quien revisa para su confirmación, en lugar de aceptarse automáticamente.

Páginas relacionadas

• Detección de amenazas
• Detección de vulnerabilidades
• Registros de auditoría
• Notificaciones