Cumplimiento de PCI DSS gratis vs de pago: lo que realmente funciona

Resumen: cumplimiento gratuito de PCI DSS 6.4.3 y 11.6.1

• Base gratuita: Puedes cumplir el baseline de 6.4.3 y 11.6.1 a coste cero en una plataforma de monitoreo de scripts de nivel gratuito. Inventario, flujo de autorización, detección de manipulación, evidencia lista para QSA.
• Cuándo compensa pagar: Los niveles de pago añaden bloqueo automatizado, retención más larga, alertas más completas, RBAC. Por encima del Nivel 3, eso normalmente se amortiza solo.
• Fecha límite: Ambos son obligatorios desde el 31 de marzo de 2025. Posponerlos supone un riesgo de suspenso ante el QSA en tu próxima evaluación.

¿Poco tiempo? Consulta cside PCI Shield. Cubre todo lo de abajo en un solo despliegue.

Por qué se establecieron estos requisitos

Desde que JavaScript se incorporó a los navegadores en 2011, la ejecución del lado del cliente ha abierto la puerta a ataques masivos de skimming de tarjetas. Los actores sofisticados inyectan ahora scripts maliciosos a través de dependencias, plugins o compromisos en la cadena de suministro, poniendo en riesgo la seguridad de los datos de tarjetas de pago. Lo más habitual es que exfiltren datos de pago de forma dinámica, dirigiéndose a menudo solo a un pequeño porcentaje de usuarios para pasar desapercibidos.

Visa, Mastercard y Amex han señalado los ataques basados en scripts del lado del cliente como la principal fuente de robo de datos de tarjetas de crédito. La tokenización ayuda, pero solo hasta cierto punto. Si el cliente se ve comprometido, el ataque sigue teniendo éxito.

Por eso PCI DSS v4.0 exige, con razón, que las empresas implementen controles para:

• Impedir la ejecución de scripts no autorizados (6.4.3)
• Garantizar la integridad de los scripts (6.4.3)
• Mantener un inventario actualizado de scripts con justificaciones de negocio (6.4.3)
• Detectar manipulaciones o modificaciones no autorizadas en las páginas de pago (11.6.1)

Cómo lograr el cumplimiento de PCI DSS sin comprar una solución

Si eres ingenioso, tienes capacidad técnica y estás dispuesto a mantener las herramientas por tu cuenta, así es como puedes hacerlo.

1. Prevenir scripts no autorizados (6.4.3)

Para cumplir el requisito de garantizar que solo se carguen y ejecuten scripts autorizados, necesitas una capa de aplicación robusta. Una Content Security Policy (CSP) puede cumplir este propósito, pero debe configurarse de forma estricta y mantenerse activamente.

Lo que puedes hacer:

• Desplegar una cabecera CSP estricta usando script-src para incluir en la lista blanca los dominios permitidos.
• Usar nonces o hashes para permitir explícitamente scripts en línea o dinámicos.
• Auditar tu política con regularidad y actualizarla con cualquier cambio en los scripts.

¿Es suficiente para PCI? Sí, PERO solo en términos formales. Los scripts dinámicos NO pueden protegerse por completo con CSP.

CSP está reconocido como un control válido para autorizar scripts. Sin embargo, CSP por sí solo no rastrea la intención. Necesitas documentación de respaldo que demuestre por qué se autorizó cada fuente permitida.

PERO, recuerda la frase de más arriba:

"Para que los comerciantes califiquen para SAQ A, deben confirmar que su sitio no es susceptible a ataques de scripts que puedan afectar los sistemas de comercio electrónico del comerciante".

¿Resuelve CSP esto en este contexto? NO. Si una fuente permanece igual pero el contenido del script entregado cambia, una CSP NO lo detectaría.

El ataque a Polyfill de 2024 NO habría sido detenido por una CSP. Esto significa técnicamente que tu sitio SÍ es susceptible a ataques, por lo que necesitas una herramienta de seguridad para cumplir plenamente. Puedes registrarte o reservar una demo para hablar con nosotros.

Ten en cuenta lo siguiente como parte de tu checklist de cumplimiento de PCI:

• Usa CSP con restricciones script-src y nonces/hashes.
• La CSP debe actualizarse y auditarse con regularidad.
• Gestiona la CSP con cuidado; es frágil y puede romper aplicaciones.

2. Verificar la integridad de los scripts (6.4.3)

Se espera que detectes cuándo un script ha sido manipulado. Para scripts estáticos, Subresource Integrity (SRI) es una solución estándar. Verifica que solo se carguen con éxito los scripts con el hash esperado.

Lo que puedes hacer:

• Añadir los atributos integrity y crossorigin a cada etiqueta `` de terceros.
• Obtener periódicamente los scripts, calcular su hash y compararlo con hashes conocidos como válidos.

¿Es suficiente para PCI? Sí, PERO solo para scripts estáticos. Los scripts dinámicos NO pueden cubrirse solo con SRI.

Los scripts dinámicos (por ejemplo, herramientas de analítica, ejecutores de pruebas A/B) suelen cambiar con cada solicitud y romperán SRI. PCI espera que reconozcas y mitigues esta limitación, ya sea evitando los scripts dinámicos o implementando una forma de monitoreo.

¿Cómo monitorearlos? Eso no es posible sin herramientas. O bien una solución de pago (como nosotros en cside 👋), o una solución construida por ti mismo.

Sin entrar en demasiado detalle, así es como podrías construir tu propia herramienta de monitoreo:

1. Crear una lista de URLs de scripts dinámicos
2. Obtener el contenido de los scripts
3. Normalizar el payload. Eliminar marcas de tiempo, cache-busters o cabeceras de seguimiento de CDN (si es necesario).
4. Guardar una versión limpia del contenido para su comparación.

Calcular el hash o comparar el resultado

1. Si hay cambios: registrarlo y alertar.

Alertar sobre cambios inesperados

1. Enviar un correo electrónico, por ejemplo.

Documentar el proceso

1. PCI quiere evidencia de que estás monitoreando activamente la integridad de los scripts.
2. Mantén registros de estas verificaciones y de las acciones resultantes.

Sin embargo, ¿es esto factible en la práctica?

¿Construirías tu propio software antivirus, por ejemplo? Diríamos que para la mayoría de nosotros la respuesta es un claro "no". Construir un motor que detecte comportamientos maliciosos en JS es algo difícil y requiere un conjunto de datos sustancial para tener éxito. Esto va más allá de un simple problema de tiempo invertido. También es un problema de recursos.

Resumen:

• SRI solo funciona para scripts estáticos. Úsalo donde sea posible.
• SRI NO funciona con scripts que tienen payloads variables.
• Es necesario monitorear el contenido real de los scripts mediante herramientas.

3. Mantener un inventario de scripts (6.4.3)

Se espera que mantengas un inventario de todos los scripts que se ejecutan en la página de pago. Esto incluye tanto scripts estáticos como dinámicos, así como scripts en línea, fuentes de terceros (como gestores de etiquetas o herramientas de analítica) y cualquier cosa cargada a través de frameworks (como React o Vue). PCI quiere ver que cada script ha sido revisado, aprobado y cuenta con una justificación de negocio o técnica. Esto, cada 7 días (de forma semanal).

Lo que puedes hacer:

• Crear una lista con control de versiones (hoja de cálculo o archivo YAML/JSON).
• Incluir: fuente del script, hash esperado (si es estático), justificación de negocio/técnica, propietario/equipo.
• Actualizarla con cada despliegue o cambio de código (no cambios en el código del script) que afecte a la página de pago.

Esto es lo que debes incluir:

• La fuente o URL
• Si es estático o dinámico
• Un hash (si es estático y se usa SRI)
• Justificación de negocio/técnica
• Propietario o equipo responsable
• Notas sobre el monitoreo (especialmente para scripts dinámicos)

Guías relacionadas

Profundiza en el clúster:

• Responsabilidades compartidas de PCI DSS con Stripe
• Responsabilidades compartidas de PCI DSS con Adyen
• Responsabilidades compartidas de PCI DSS con PayPal Braintree
• Comparativa de soluciones para PCI DSS 6.4.3 y 11.6.1
• vikingcloud-approves-c-sides-security-platform-for-pci-dss-v4-0-1-requirement-6-4-3-and-11-6-1
• Cómo cumplir con PCI DSS 6.4.3
• Las actualizaciones de enero de 2025 al PCI DSS SAQ A, explicadas

¿Es suficiente para PCI? Sí, PCI no exige nada más en este punto. Una lista manual es aceptable siempre que sea precisa y se mantenga actualizada. Los scripts dinámicos igualmente deben estar listados, aunque no puedas calcular su hash. En esos casos, PCI espera que expliques por qué no se puede usar SRI y cómo se está monitoreando el script en su lugar. NOTA: Esto NO significa que puedas simplemente hacer un inventario y no actuar sobre los puntos anteriores. Es un requisito descrito de forma algo más laxa que algunos consideran la solución definitiva. No lo es.

4. Detección de manipulaciones y cambios (11.6.1)

PCI quiere que detectes cambios no autorizados en la página de pago tal como la recibe el navegador del usuario. Esto incluye cambios en el contenido y en las cabeceras HTTP (como CSP, CORS, etc.).

Lo que puedes hacer:

• Usar un navegador headless (por ejemplo, Puppeteer) o curl para obtener la página de pago en vivo. Tendrás que gastar dinero en eso...
• Capturar cabeceras y contenido HTML.
• Comparar con una línea base conocida como válida y alertar sobre los cambios.
• Normalizar la salida si es necesario para evitar falsos positivos (especialmente importante para el contenido dinámico).
• Documentar qué cambios disparan alertas, quién responde y cómo.

¿Es suficiente para PCI? Sí, SIEMPRE QUE lo ejecutes con regularidad y hayas documentado qué cambios disparan alertas, quién es notificado y cuál es tu plan de respuesta. La cadencia requerida es semanal, A MENOS QUE se justifique lo contrario mediante un análisis de riesgos.

Nota sobre páginas dinámicas: Los frameworks renderizados en el cliente (React, Vue, etc.) suelen cargar o mutar el DOM después de que la página se ha cargado. Si no tienes esto en cuenta, tu monitoreo generará falsos positivos. Para PCI, esto es, en principio, aceptable, SIEMPRE QUE definas claramente qué es lo que sí verificas (por ejemplo, la cabecera CSP, los dominios de scripts externos, selectores DOM clave) y por qué. Si aun así sufres un ataque, el requisito se mantiene: "Para que los comerciantes califiquen para SAQ A, deben confirmar que su sitio no es susceptible a ataques de scripts que puedan afectar los sistemas de comercio electrónico del comerciante".

Resumen:

• Usa curl o un navegador headless para capturar y comparar cabeceras y HTML.
• Normaliza el contenido dinámico para reducir los falsos positivos.
• Ejecuta las verificaciones semanalmente (o con mayor frecuencia según el riesgo).
• Configura las alertas y un proceso de respuesta documentado.

Qué comprueba una auditoría de cumplimiento de PCI DSS 4.0.1 sobre 6.4.3 y 11.6.1

Una auditoría de cumplimiento de PCI DSS 4.0.1 para comercios de ecommerce examina si el inventario de la página de pago está completo, si cada script cuenta con una justificación de negocio o técnica autorizada, y si el comercio puede demostrar que se ejecuta un mecanismo de detección de cambios contra las cabeceras HTTP de la página de pago al menos una vez cada siete días. Los requisitos 6.4.3 y 11.6.1 son las dos cláusulas a las que un QSA dedicará más tiempo en los flujos card-not-present.

Los artefactos visibles en la auditoría son concretos: una lista de inventario de scripts con propietario, propósito y hash esperado por cada entrada; aprobaciones documentadas; y evidencia en registros de que el mecanismo de detección de cambios se ha ejecutado con la cadencia requerida, con alertas que llegan a un canal monitorizado. Si falta alguno de esos artefactos o no puede reproducirse bajo demanda, la auditoría marcará 6.4.3 u 11.6.1 como no conforme, con independencia de la calidad del resto de controles.

cside genera el inventario de scripts de forma automática a partir de los datos en vivo de la página de pago, mantiene los hashes y el estado de aprobación, y ejecuta el bucle de detección de cambios de 6.4.3 de forma continua con una traza de evidencia que un QSA puede extraer directamente.

Los beneficios de negocio del cumplimiento de PCI DSS más allá de evitar multas

Los beneficios del cumplimiento de PCI DSS más allá de evitar multas son concretos: estabilidad de la relación con el adquirente, confianza de las marcas de pago y un coste de respuesta a incidentes materialmente menor si llega a producirse una brecha. Los comercios que cumplen de forma continua mantienen su relación con el adquirente fuera de la cola de escalado, conservan el acceso a las bandas de interchange más bajas que ofrece su procesador y reducen el volumen de trabajo forense que dispara un incidente.

También existe un beneficio indirecto para los grandes compradores de ecommerce. Los equipos de compras de las empresas exigen cada vez más la certificación PCI DSS como requisito previo para un proveedor. El cumplimiento continuo significa que el AoC está siempre al día cuando llega una solicitud de compra, en lugar de una carrera contrarreloj en cada ciclo anual.

La monitorización continua de cside mantiene la cadena de evidencia de 6.4.3 y 11.6.1 al día en tiempo real, lo que hace que la ventana de preparación de la auditoría pase de semanas de puesta al día a una exportación en el mismo día.

El incumplimiento de PCI DSS y las penalizaciones que realmente afrontan los comercios

El incumplimiento de PCI DSS conlleva tres niveles de sanción que golpean directamente a los comercios. Las redes de tarjetas imponen multas a través del adquirente, que suelen empezar en unos pocos miles de dólares al mes por una primera infracción y escalar a importes mensuales de cinco o seis cifras si el comercio sigue sin cumplir a lo largo de varios ciclos de auditoría. El adquirente a menudo repercute estas multas en su totalidad y añade su propio recargo por servicio.

El segundo nivel es el coste a nivel de transacción. Un comercio declarado no conforme en el momento de la brecha se enfrenta a tarifas de interchange más altas en transacciones posteriores y a mayor responsabilidad por contracargos. Las penalizaciones por incumplimiento de PCI DSS se suman a la responsabilidad derivada de la brecha bajo la legislación estatal y federal.

El tercer nivel es la sanción estratégica. El incumplimiento persistente puede llevar a la pérdida de los derechos de procesamiento de tarjetas o a la inclusión en el listado MATCH, que restringe la capacidad del comercio para obtener procesamiento de pagos de otros adquirentes.

cside reduce tanto el riesgo de incumplimiento como el coste de preparación de la auditoría al mantener los controles 6.4.3 y 11.6.1 en un estado continuamente verificable.

Una checklist concisa de cumplimiento de PCI DSS 4.0.1 para 6.4.3 y 11.6.1

Una checklist de cumplimiento de PCI DSS 4.0.1 para los requisitos de página de pago 6.4.3 y 11.6.1 es breve pero estricta. Recórrela en orden antes de una auditoría:

1. Inventario completo de scripts. Cada script que se carga en la página de pago aparece listado con su fuente, propósito, responsable de negocio y hash esperado cuando el script es estático.
2. Aprobación documentada por script. Cada entrada tiene una decisión de aprobación registrada por una persona responsable y una marca temporal de revisión dentro del último ciclo de revisión.
3. Mecanismo de detección de cambios instalado. Una herramienta o proceso detecta cambios no autorizados en las cabeceras HTTP y el contenido de los scripts de la página de pago, y puede generar evidencia de sus ejecuciones.
4. Cadencia semanal demostrada. La evidencia en registros muestra que el mecanismo de detección de cambios se ejecutó al menos cada siete días durante todo el periodo de auditoría.
5. Enrutado de alertas verificado. Las alertas llegan a un canal monitorizado con una vía de escalado hacia seguridad o ingeniería.
6. Evidencia de prueba de disparo. Un cambio de prueba en una página de pago que no está en producción fue detectado y generó una alerta dentro de la ventana requerida.
7. Controles compensatorios documentados, si se usan. Cualquier desviación del enfoque estándar está documentada con la justificación del control compensatorio.

cside genera los puntos 1 a 6 como evidencia continua, de modo que la auditoría se convierte en una revisión del sistema en funcionamiento en lugar de una reconstrucción a posteriori.

Entonces, ¿puedes hacerlo "gratis"?

Sí, más o menos. Pero es prácticamente imposible.

Es técnicamente posible, pero frágil en la práctica y en cuanto a compatibilidad. Y lo más importante: es más que probable que acabes gastando más dinero, tiempo y recursos que si optaras por una solución de pago.

Necesitarías:

• Escribir tus propias herramientas o scripts.
• Construir tu propio método para analizar scripts: esto es costoso y, como empresa que no se dedica a la seguridad, probablemente no tendrías acceso a los datos ni a las competencias necesarias para hacerlo. ¿Construirías tu propio antivirus?
• Monitorear la integridad de los scripts manualmente.
• Mantener un inventario de scripts con disciplina.
• Normalizar y comparar páginas dinámicas sin ahogarte en falsos positivos.

Y, lo más importante: Necesitas demostrar que tu sitio no es susceptible a ataques del lado del cliente, tal como exige explícitamente la actualización de PCI DSS de enero.

Una CSP no detendrá los ataques a la cadena de suministro. Una SRI no es compatible con scripts dinámicos. Y una verificación básica con curl no protegerá contra la exfiltración selectiva y sensible al contexto.

Si vas por la vía DIY: documenta todo, automatiza donde puedas y prepárate para la carga de trabajo adicional. Y, si es posible, construye tus propias herramientas. Pero, sobre todo, calcula tu tiempo y tus recursos (humanos o de otro tipo) y haz números. Lo más probable es que salgas mejor parado optando por una solución de pago.

Si buscas cumplir por completo y estar seguro, construimos cside precisamente para eso. Puedes reservar una demo aquí o registrarte para estar en cumplimiento hoy mismo.

Entendiendo específicamente PCI 11.6.1

Mientras que 6.4.3 se centra en el inventario y la justificación de scripts, PCI DSS 11.6.1 se centra en detectar cambios no autorizados en los scripts y en las cabeceras HTTP de seguridad de las páginas de pago.

PCI 11.6.1 exige que:

• Monitorees el contenido y la configuración de cada script que se ejecuta en las páginas de pago.
• Detectes manipulación, inyección o modificación no autorizada de manera oportuna.
• Alertes al personal correspondiente cuando se detecten cambios no autorizados.

La palabra "oportuna" se deja intencionadamente a la interpretación del QSA, pero en general se entiende como una detección en cuestión de minutos u horas tras el cambio. Los escaneos semanales o mensuales no satisfacen 11.6.1. El monitoreo continuo de cside dispara alertas en tiempo real a medida que ocurren los cambios, dando a tu equipo de seguridad la ventana de respuesta que exige el cumplimiento.