En este artículo:
- Qué buscan los auditores en el cumplimiento de PCI 6.4.3 y 11.6.1
- Ejemplos de ataques y multas
- Comparación de soluciones de proveedores
- Recursos para tu equipo (checklists, evaluaciones)
PCI 6.4.3 y 11.6.1 tratan de una sola cosa: control y visibilidad sobre lo que se ejecuta en el navegador de tus usuarios. Específicamente en las páginas de pago. Estos requisitos obligan a las empresas a entender por fin qué ocurre en el lado del cliente: ¿qué scripts se están cargando? ¿Fueron aprobados? ¿Están teniendo un comportamiento sospechoso? Sorprendentemente, la mayoría de los equipos no tienen respuesta a esas preguntas. Nunca tuvieron que tenerla. Y ahora esos equipos están corriendo para cumplir con las auditorías de PCI DSS 4.0.1. Según el Informe de Seguridad de Pagos 2024 de Verizon, el porcentaje de organizaciones que mantienen el cumplimiento total ha disminuido de forma constante, hasta el 33% en 2023.
Hemos trabajado con diversos líderes de seguridad en eCommerce, Retail y FinTech para implementar soluciones conformes con PCI en páginas que manejan datos sensibles de usuarios (como tarjetas de pago). Tras observar los errores más comunes y las mejores prácticas, compilamos una guía con nuestros aprendizajes para facilitar tu proceso de cumplimiento.
"Los pasos técnicos para lograr el cumplimiento de PCI 6.4.3 & 11.6.1 es algo que me piden explicar regularmente a los equipos de cumplimiento. Los documentos son claros sobre lo que se requiere, pero cómo implementar los mecanismos sigue siendo un área gris que los equipos de seguridad deben resolver".
— Simon Wijckmans, Fundador, cside
¿Cuáles son los requisitos de PCI DSS 6.4.3?
Como parte de las incorporaciones de PCI DSS 4.0.1 que se volvieron obligatorias el 31 de marzo de 2025, el requisito 6.4.3 exige a las empresas:
- Mantener un inventario de cada script que se ejecuta en las páginas de pago.
- Documentar por qué se necesita cada script (justificación comercial).
- Verificar la integridad de cada script (asegurándose de que no haya sido alterado).
- Detectar y alertar sobre cambios no autorizados en los scripts.
Lo que esto significa en términos simples: En las páginas que manejan información sensible de los usuarios (tarjetas de pago, información de salud, PII) necesitas tener un mecanismo para monitorear los scripts de terceros, lo que hacen en los navegadores de tus usuarios, y alertar a los equipos de seguridad cuando los scripts tienen un comportamiento sospechoso.
*Definiciones basadas en PCI DSS v4.0.1 - Jun. 2024. Esta es la versión más actualizada a septiembre de 2025. Para consultar los documentos oficiales, visita la biblioteca del PCI SSC.
¿Cuáles son los requisitos de PCI DSS 11.6.1?
Como parte de las incorporaciones de PCI DSS 4.0.1 que se volvieron obligatorias el 31 de marzo de 2025, el requisito 11.6.1 exige a las empresas:
- Alertar al personal sobre cambios no autorizados en las cabeceras HTTP y los scripts de las páginas de pago
- Evaluar las cabeceras HTTP recibidas y las páginas de pago
- Operar al menos semanalmente o según el análisis de riesgos de la entidad (Requisito 12.3.1)
Lo que esto significa en términos simples: Las cabeceras HTTP son reglas que indican al navegador del usuario cómo manejar el contenido de una página. Alterar esas cabeceras (por ejemplo, mediante un script malicioso) puede debilitar las protecciones de seguridad. PCI DSS 11.6.1 exige a las empresas tener un mecanismo que compruebe regularmente (al menos una vez cada siete días) si hay cambios no autorizados en las cabeceras y que alerte al equipo de seguridad cuando se produzcan.
Métodos para lograr el cumplimiento de 6.4.3 y 11.6.1 (comprar o construir):
- Construir una solución interna: Crear herramientas internas para rastrear páginas de pago, registrar scripts, analizar sus cargas útiles y alertar sobre cambios. Este enfoque requiere tiempo de ingeniería continuo por parte de personal especializado.
- Usar una herramienta preconfigurada: Una plataforma de inteligencia del lado del cliente mantendrá automáticamente un inventario de scripts en tiempo real, proporcionará justificaciones y enviará alertas sobre cambios no autorizados. Las funciones de reporte suelen estar diseñadas específicamente para auditorías de PCI DSS.
"En cuanto a si debo construirlo internamente o comprar una herramienta: es una decisión individual para cada empresa. Pero aún no he tenido un cliente que lo haya hecho correctamente de forma interna. En toda nuestra empresa, solo he visto un cliente que lo haya logrado con éxito internamente. Y eso después de trabajar con cientos de clientes. Una herramienta de proveedor realmente elimina las conjeturas."
- Marc Jackson, QSA y Asesor de Cumplimiento, MegaplanIT
Desglose de PCI DSS 6.4.3 y pasos para el cumplimiento
Quién es responsable del cumplimiento de 6.4.3 y 11.6.1:
- Los desarrolladores controlan qué scripts se despliegan y mantienen el inventario actualizado.
- Los equipos de seguridad monitorean cambios sospechosos e investigan las alertas.
- Los equipos de cumplimiento garantizan que la documentación, las aprobaciones y los registros de auditoría cumplan con los estándares de PCI.
Cómo es el reporte aprobado por QSA para 6.4.3 y 11.6.1:
Algunas herramientas de bajo costo o gratuitas exportan dashboards desordenados o archivos CSV. Estos son difíciles de interpretar para los auditores y aún más difíciles de operacionalizar para los equipos internos. En la práctica, los QSA buscan reportes estructurados y revisables que muestren el inventario de scripts, el estado de autorización y la detección de cambios a lo largo del tiempo. Un reporte limpio también facilita que tu equipo actúe rápidamente ante comportamientos sospechosos.
Este video recorre los reportes que usamos tanto como empresa auditada de forma independiente bajo SAQ-D como en nuestra calidad de proveedor con controles validados por VikingCloud.
<a
class="pci-video-card__cta"
href="https://cside.com/landing/pci-demo-video"
target="_blank"
rel="noopener noreferrer"
>
<span class="pci-video-card__icon" aria-hidden="true">
<svg viewBox="0 0 48 48" fill="none" xmlns="http://www.w3.org/2000/svg">
<circle cx="24" cy="24" r="20.5" stroke="currentColor" stroke-width="2"/>
<path d="M20 16.5L31 24L20 31.5V16.5Z" stroke="currentColor" stroke-width="2" stroke-linejoin="round"/>
</svg>
</span>
<span>Ver video</span>
</a>
Qué buscan los auditores en el cumplimiento de PCI 6.4.3
1. Mantener un inventario de cada script que se ejecuta en las páginas de pago
"Uso muchísimos scripts de terceros: herramientas de analítica, widgets de soporte, polyfills, librerías de animación, CDNs. Cualquiera de estos podría volverse malicioso y reemplazar el contenido legítimo con un keylogger o algo peor." - Edgardo C., Desarrollador (Cita tomada de una reseña de cside)
La mayoría de los sitios web tienen entre 5 y más de 100 scripts. Una plataforma de inteligencia del lado del cliente mantiene un inventario en todas las páginas (incluidas las páginas de pago de tu dominio) y muestra la carga útil del script en cada solicitud. Esto te permite ver cambios en el código, actualizaciones y posibles acciones maliciosas. Todo se organiza de forma clara en un dashboard para que las partes interesadas tengan visibilidad. Aunque no es un requisito de PCI DSS 4.0.1, algunas plataformas también bloquean y alertan sobre cambios (maliciosos).
2. Documentar por qué se necesita cada script con una justificación comercial (PCI 6.4.3)
Cumplir este requisito de forma manual suele seguir este proceso:
-
- Exportar una lista de scripts desde un crawler web o una herramienta de navegador, 2. Identificar al responsable de cada script (interno, proveedor), 3. Registrar todo en un documento central (p. ej., una hoja de cálculo), 4. Añadir un campo de texto con la justificación de por qué el script es necesario, 5. Actualizar el documento cada vez que se añadan, eliminen o modifiquen scripts.
Una plataforma de inteligencia del lado del cliente:
- Almacena cada justificación directamente junto al script en tu inventario, asegurando que el contexto esté siempre actualizado en un lugar centralizado.
- Genera justificaciones con IA para cada script, lo que da a los equipos un punto de partida ya redactado que pueden revisar, aprobar o ajustar.
3. Verificar la integridad de cada script para asegurarse de que no haya sido alterado (PCI 6.4.3)
Los actores maliciosos pueden modificar scripts para que se comporten de formas distintas a las originalmente previstas. Por ejemplo:
- Modificar formularios de pago para enviar datos a un servidor controlado por el atacante (exfiltración de datos)
- Añadir campos de entrada ocultos o keyloggers para capturar las credenciales de los titulares de tarjetas
Por eso son fundamentales las soluciones multicapa que analizan JavaScript durante cada sesión en vivo. Ven cada script exactamente como se ejecuta en el navegador del usuario, lo que facilita a los ingenieros entender qué está haciendo el script. La IA también filtra los cambios y ofrece información sobre qué podría hacer la funcionalidad añadida o modificada.
4. Detectar y alertar sobre cambios no autorizados en los scripts (PCI 6.4.3)
Necesitas mostrar a los auditores cómo han cambiado los scripts a lo largo del tiempo. Una técnica de ataque habitual consiste en hacer pequeñas modificaciones a scripts existentes. Estos cambios pasan desapercibidos con frecuencia porque los equipos de seguridad no pueden (ni de forma realista podrían) revisar manualmente los cambios de código de cada script de forma continua. Una herramienta de monitoreo automatizado rastreará estos cambios y registrará marcas de tiempo para darte un historial claro al que hacer referencia.
Desglose de PCI DSS 11.6.1 y pasos para el cumplimiento
El requisito 11.6.1 es algo más técnico. Establece que el personal debe ser alertado cuando cambien las cabeceras HTTP y los scripts de las páginas de pago. Esto es prácticamente imposible de hacer de forma manual. El JavaScript de terceros no está diseñado para permanecer estático. Se actualiza según la ubicación del usuario, el tipo de navegador y la hora del día. Algunos scripts necesitan servir versiones diferentes por razones funcionales. Entonces, ¿cómo puedes ver, y mucho menos entender, estos cambios?
Qué buscan los auditores en el cumplimiento de PCI 11.6.1
1. Alertar al personal sobre cambios no autorizados en las cabeceras HTTP y los scripts de las páginas de pago (PCI 11.6.1)
Las cabeceras HTTP son reglas que indican al navegador del usuario cómo manejar el contenido de una página. Si se modifican, suponen un riesgo de seguridad. Una solución de seguridad web del lado del cliente monitorea los datos de los scripts para detectar diferencias de comportamiento entre sesiones separadas.
2. Evaluar las cabeceras HTTP recibidas y las páginas de pago (PCI 11.6.1)
Evaluar las cabeceras HTTP significa vigilar aspectos como las políticas de seguridad de contenido. Hacerlo manualmente página por página inevitablemente llevará a pasar por alto señales importantes. Una herramienta de seguridad del lado del cliente lo hace automáticamente, de modo que cada cabecera queda validada y el proceso de evaluación requiere menos intervención manual de tu equipo.
3. Operar al menos semanalmente o según el análisis de riesgos de la entidad (PCI 11.6.1 y 12.3.1)
PCI DSS te ofrece dos opciones aquí. Ejecutar las comprobaciones al menos una vez a la semana. O ejecutarlas con mayor frecuencia si tu propio análisis de riesgos así lo indica. Si se hace manualmente, alguien tendría que cargar la página de pago, extraer las cabeceras HTTP, compararlas con la copia de la semana anterior y hacer lo mismo con el contenido de la página. Luego documentarlo todo cada semana, o con más frecuencia si tu perfil de riesgo lo exige.
cside registra las cabeceras cada vez que se carga tu página, por lo que no tienes que hacer comparaciones manuales. Los reportes se envían a tu bandeja de entrada de forma regular (p. ej., semanalmente) y se almacenan en la plataforma. Esto crea un registro completo en papel para el cumplimiento.
Por qué importa el cumplimiento de PCI (Ejemplos de ataques y multas)
PCI DSS existe para proteger a los usuarios de internet del robo de información de pago. Más de 72.000 sitios web fueron comprometidos solo en el segundo trimestre de 2025. Si los hackers consiguen acceso para editar código que se carga en un navegador, pueden robar mucho más que información de tarjetas de crédito. Roban identidades. Vacían cuentas bancarias. Dejan a las personas lidiando con un problema que puede tardar meses en resolverse. Seguir las reglas de PCI te ayuda a evitar multas que van de 5.000 a 100.000 dólares. También te protege de filtraciones de datos del lado del cliente que cuestan a las empresas más de 20 millones de dólares, además de la pérdida de la confianza de los consumidores.
Comparación de herramientas para PCI 6.4.3 y 11.6.1
Muchas soluciones de PCI buscan marcar la casilla de cumplimiento sin ofrecer una protección real a tus usuarios. Otras soluciones utilizan tecnología obsoleta, dejando a los clientes sorprendidos cuando no superan las auditorías de PCI tras una implementación de varios meses. Asegúrate de que la solución de tu proveedor haya sido revisada y aprobada por un QSA (Qualified Security Assessor) acreditado.
Diferentes enfoques técnicos para PCI 6.4.3 y 11.6.1
El siguiente desglose está tomado de la Comparación de tecnologías de seguridad del lado del cliente:
Los enfoques basados en crawlers escanean la página a posteriori, y a menudo solo de forma periódica. No logran imitar el comportamiento real del usuario, y los atacantes pueden evadir fácilmente la detección sirviendo scripts limpios a los crawlers mientras apuntan a los usuarios reales con cargas maliciosas.
Las políticas de seguridad de contenido (CSP) tienen un alcance limitado. Abordan el origen del script en lugar de su carga útil. Cuando el origen es vulnerado, pasa desapercibido. Cuando se usa un script dinámico, una Content Security Policy no tiene forma de saber qué está sirviendo realmente ese script.
La detección de JS del lado del cliente (también llamada Agentes) inyecta scripts de monitoreo en los navegadores. Establece trampas para intentar detectar JavaScript malicioso. Sin embargo, estas trampas suelen ser fácilmente detectables y, por tanto, evitables.
cside aborda todos los problemas mencionados anteriormente mediante una solución multicapa que incluye agentes JS, escáneres, CSPs, feeds de amenazas y más. La plataforma cside también obtiene scripts en sus propios servidores de forma asíncrona para una inspección exhaustiva sin introducir fricción en los flujos de usuario.
Herramientas populares para PCI 6.4.3 y 11.6.1
| Nombre | Enfoque | Reseñas | Más información |
|---|---|---|---|
| cside | Enfoque multicapa con JavaScript Agent | ★★★★★ (4,9 estrellas) en G2 | Evaluación de la solución cside |
| Feroot | Detección basada en JavaScript | ★★★★★ (4,8 estrellas) en G2 | Evaluación de la solución Feroot |
| Imperva | Content Security Policy (CSP) | ★★★★☆ (4,5 estrellas) en G2 | Evaluación de la solución Imperva |
| DataDome | JavaScript Agent | ★★★★★ (4,8 estrellas) en G2 | Evaluación de la solución DataDome |
| JScrambler | JavaScript Agent | ★★★★☆ (4,3 estrellas) en G2 | Evaluación de la solución JScrambler |
"Las capacidades de detección que obtuvimos con cside no se parecían a nada de lo que vimos en otros productos que probamos en el pasado. Definitivamente recomendaríamos el producto para PCI y más." - Mark D., (Cita de la reseña en G2 de cside)
Sub Resource Integrity (SRI) para el cumplimiento de PCI DSS
En el documento PCI DSS v4.0.1, el PCI SSC menciona SRI (sub-resource integrity) como un mecanismo válido para verificar la integridad de los scripts y cumplir con el requisito 6.4.3. Puedes leer más sobre Sub Resource Integrity aquí para entender cómo funciona.
Por qué SRI por sí solo falla en PCI DSS 6.4.3 en la práctica
Sub Resource Integrity funciona bien para scripts estáticos, pero falla cuando se trata de scripts dinámicos. Muchos scripts web de terceros son dinámicos y se actualizan con frecuencia. Cada cambio legítimo requiere volver a calcular el hash y redesplegar, lo que rápidamente se vuelve inmanejable. Si tu sitio tiene un equipo de marketing, probablemente tengas scripts dinámicos: piensa en etiquetas de analítica, herramientas de pruebas A/B o píxeles de seguimiento.
Por lo tanto, SRI no es un método de cumplimiento de PCI DSS ni de seguridad viable para un entorno web con scripts dinámicos.
Combinar SRI con una directiva CSP (script-src) refuerza la protección, pero este enfoque también falla cuando los scripts se actualizan con frecuencia. Cualquier cambio legítimo en el contenido invalida el hash, lo que hace que el script deje de cargarse y posiblemente rompa la funcionalidad de tu sitio.
Alternativa a SRI para verificar la integridad de los scripts:
En lugar de depender del mantenimiento manual de CSP y SRI para el cumplimiento de PCI DSS, puedes desplegar una herramienta de monitoreo de integridad de scripts. Las soluciones modernas como cside escanean continuamente en busca de modificaciones sospechosas y alertan sobre cambios basándose en una variedad de puntos de datos:
- Análisis continuo con IA: Evalúa cómo se comportan los scripts en el navegador para detectar anomalías o código inyectado
- Comparación histórica de hashes: Rastrea cambios entre versiones anteriores del script para un análisis forense preciso de manipulaciones o actualizaciones
- Inteligencia de amenazas: Cruza los scripts con exposiciones conocidas de la cadena de suministro web que afectan a los scripts de tu sitio.
Obtén ayuda de nuestro equipo
¿Necesitas claridad sobre PCI 6.4.3 o 11.6.1? Nuestro equipo puede evaluar los puntos ciegos en tu infraestructura actual y mostrarte cómo cside facilita el cumplimiento.
cside te da todo lo que necesitas para superar PCI 6.4.3 y 11.6.1.
✓ Inventaría automáticamente cada script en tus páginas de pago y rastrea los cambios en tiempo real.
✓ Almacena justificaciones y ahorra horas de trabajo con justificaciones generadas por IA para que las apruebes o edites.
✓ Monitorea las cabeceras HTTP y detecta modificaciones no autorizadas, alertando a tu equipo al instante.
Checklist resumido para PCI DSS 6.4.3 y 11.6.1
Para 6.4.3 y 11.6.1, este es el checklist resumido que repasamos en nuestra primera conversación con los equipos de seguridad:
| ◯ | ¿Tienes un mecanismo capaz de detectar scripts maliciosos? |
| ◯ | ¿Tienes un mecanismo que detenga los scripts maliciosos (y puedes demostrar que realmente verificó el código)? |
| ◯ | ¿Mantienes una lista de los scripts con justificación comercial y técnica? |
| ◯ | ¿Monitorizas las cabeceras HTTP en una página web? |
| ◯ | ¿Conoces los diferentes enfoques técnicos para la seguridad del lado del cliente? (CSP, JS Agent, Proxy) |
| ◯ | ¿Planeas cumplir con los nuevos requisitos con una solución construida internamente o con herramientas preconfiguradas? |
Preguntas frecuentes sobre PCI DSS 6.4.3 y 11.6.1
¿Estás exento de cumplir con PCI 6.4.3 y 11.6.1? (Autoevaluación para SAQ A)
La actualización de enero de 2025 de PCI DSS al SAQ A introdujo posibles exenciones de 6.4.3 y 11.6.1, pero los criterios están redactados en términos vagos y de alto nivel. En la práctica, tendrías que demostrar que tus páginas de pago no contienen scripts de terceros ni otro contenido dinámico. Este escenario es poco frecuente para la mayoría de los comerciantes. Obtener una exención es extremadamente difícil. Para un análisis detallado de los criterios y un flujo lógico visual que puedes usar para evaluar tu propio estado, visita nuestro artículo dedicado "Qué es un SAQ A y cómo aplicarlo".
Cómo cumplir con PCI DSS 6.4.3 de forma gratuita
No existen herramientas de proveedores que te hagan cumplir completamente con PCI de forma gratuita. Algunas ofrecen una prueba gratuita o un nivel gratuito limitado, pero con cualquier volumen significativo de tráfico web estarás pagando costos basados en el uso. La otra opción es construir una solución DIY internamente. Incluso si tienes el talento de ingeniería disponible, esto termina costando mucho más que comprar una solución lista para usar. Si quieres el desglose técnico de lo que implica el camino DIY, consulta nuestro artículo: Lograr el cumplimiento de PCI sin comprar una solución.
