¿Existe algún método "gratuito" para cumplir con PCI DSS 6.4.3 y 11.6.1?

PCI DSS 6.4.3 y 11.6.1 son requisitos del lado del cliente, y la mayoría de las organizaciones nunca antes habían tenido que enfrentarlos con este nivel de escrutinio.

Entonces, ¿se puede lograr el cumplimiento de PCI con ambos requisitos sin una solución de pago? La respuesta es: No, más o menos. Pero gastarías mucho más dinero en salarios de lo que pagarías por una solución.

Esta frase importante debe estar presente en tu mente mientras lees este artículo. Fue añadida en la actualización de enero en relación con los requisitos 6.4.3 y 11.6.1.

"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".

Por qué se establecieron estos requisitos

Desde que JavaScript fue añadido 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 ahora inyectan 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. Con mayor frecuencia, exfiltran datos de pago de forma dinámica, apuntando 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 es comprometido, el ataque sigue teniendo éxito.

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

• Prevenir 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 con 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:

• Implementar 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 regularmente tu política 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 completamente con CSP.

CSP es 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é cada fuente permitida fue autorizada.

PERO, recuerda la frase mencionada anteriormente:

"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 de Polyfill de 2024 NO habría sido detenido por una CSP. Técnicamente, esto significa 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 PCI:

• Usar CSP con restricciones script-src y nonces/hashes.
• La CSP debe actualizarse y auditarse regularmente.
• Gestionar 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 correctamente los scripts con el hash esperado.

Lo que puedes hacer:

• Añadir los atributos integrity y crossorigin a cada etiqueta <script> de terceros.
• Obtener periódicamente los scripts, calcular su hash y compararlo con los 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 mitiges 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. Ya sea 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 comparación.

Calcular el hash o comparar el resultado

1. Si hay cambios: registrar y alertar.

Alertar sobre cambios inesperados

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

Documentar el proceso

1. PCI requiere evidencia de que estás monitoreando activamente la integridad de los scripts.
2. Mantener registros de estas verificaciones y de las acciones resultantes.

Sin embargo, ¿es esto prácticamente posible?

¿Construirías tu propio software antivirus, por ejemplo? Argumentaríamos que para la mayoría de nosotros la respuesta es un claro "no". Construir un motor para detectar comportamientos maliciosos en JS es algo difícil y requerirá 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 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 tiene 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 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)

¿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 ven como 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 cambios.
• Normalizar la salida si es necesario para evitar falsos positivos (especialmente importante para contenido dinámico).
• Documentar qué cambios generan alertas, quién responde y cómo.

¿Es suficiente para PCI? Sí, SIEMPRE QUE lo ejecutes regularmente y hayas documentado qué cambios generan alertas, quién es notificado y cuál es tu plan de respuesta. La frecuencia requerida es semanal, A MENOS QUE se justifique de otra manera 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 carga. Si no tienes esto en cuenta, tu monitoreo generará falsos positivos. Para PCI, esto es argumentablemente aceptable, SIEMPRE QUE definas claramente qué sí verificas (por ejemplo, cabecera CSP, dominios de scripts externos, selectores DOM clave) y por qué. Si aun así sufres un ataque, ten en cuenta la frase importante: "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:

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

Entonces, ¿puedes hacerlo de forma "gratuita"?

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

Es técnicamente posible, pero prácticamente frágil en términos de compatibilidad. Lo más importante es que, con toda probabilidad, gastarás más dinero, tiempo y recursos que optando 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 no especializada en 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 se exige explícitamente en la actualización de PCI DSS de enero.

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

Si vas por la ruta DIY: Documenta todo, automatiza donde puedas y prepárate para la carga operativa. Y construye tus propias herramientas, si es posible. Pero lo más importante es que calcules tu tiempo y recursos (humanos o de otro tipo) y hagas los números. Lo más probable es que te convenga más optar por una solución de pago.

Si buscas cumplir plenamente y estar seguro, construimos cside exactamente para eso. Puedes reservar una demo aquí o registrarte para cumplir hoy mismo.