Resumen: lista de comprobación práctica de cumplimiento PCI DSS 6.4.3 para scripts de pago
- La mayoría de los equipos toman Subresource Integrity como la respuesta a 6.4.3. No basta por sí solo: SRI no inventaría todos los scripts automáticamente, no aplica a scripts cargados dinámicamente y no detecta cambios de comportamiento en un script autorizado, que es el vector principal de ataques Magecart.
- 6.4.3 es obligatorio desde el 31 de marzo de 2025 y cubre bundles propios, etiquetas de terceros, píxeles de analítica, widgets de chat y bibliotecas CDN. cside PCI Shield se despliega como una única etiqueta de script en la página de pago, y la mayoría de los equipos completan la integración técnica en menos de 30 minutos.
- Si tu checkout corre un puñado de scripts estáticos, SRI más CSP puede sostenerse como controles base. Si un gestor de etiquetas inyecta scripts dinámicamente, añade monitorización de integridad en tiempo de ejecución, cside está validado por VikingCloud para 6.4.3 y 11.6.1.
El Requisito 6.4.3 de PCI DSS 4.0.1 te pide hacer tres cosas con cada script que se ejecuta en una página de pago: confirmar que está autorizado, guardar una justificación por escrito de por qué debe estar ahí y protegerlo con un control de integridad que detecte los cambios no autorizados. El requisito es obligatorio desde el 31 de marzo de 2025, y cubre el código propio, las etiquetas de terceros, los píxeles de analítica, los widgets de chat y cualquier otra cosa que se ejecute en el contexto de una página de pago.
Existe para combatir el skimming de páginas de pago, los ataques de tipo Magecart en los que se cuela JavaScript malicioso en una página de checkout para robar los datos de la tarjeta mientras el cliente los teclea. El Requisito 6.4.3 es uno de los dos nuevos controles del lado del cliente de PCI DSS 4.0.1, y su compañero, el 11.6.1, se encarga de la parte de monitorización. Esta lista de comprobación repasa qué pide el 6.4.3 y cómo llegar hasta ahí.
Qué exige realmente el Requisito 6.4.3
El PCI Security Standards Council define tres controles concretos dentro del Requisito 6.4.3:
1. Un método para confirmar que cada script está autorizado. Necesitas una autorización documentada para cada script presente en las páginas de pago. Eso significa no solo los scripts que ha escrito tu equipo, sino cada etiqueta de terceros, píxel de analítica, widget de chat, herramienta de test A/B y librería cargada desde un CDN que se ejecute en el contexto de una página de pago. Autorizar significa que sabes que el script está ahí y que tienes un motivo de negocio para ello.
2. Un método para garantizar la integridad de cada script. Cada script debe estar protegido frente a modificaciones no autorizadas. Puedes hacerlo con hashes de Subresource Integrity (SRI) para los scripts cargados externamente, con controles de Content Security Policy o con una herramienta de monitorización en tiempo de ejecución que avise cuando el contenido o el comportamiento de un script cambian. SRI por sí solo no cubre los scripts que se cargan dinámicamente ni los que sirve un CDN cuyo contenido rota sin que cambie la URL.
3. Una justificación por escrito para cada script. Cada script autorizado necesita un motivo de negocio documentado para estar en la página de pago. Una etiqueta que está presente solo porque marketing la añadió hace tres años y nadie la quitó no tiene justificación. Tu evaluador pedirá esta documentación.
El requisito compañero, el 11.6.1, añade la detección de cambios y manipulaciones: un mecanismo automatizado que avisa cuando se modifican los scripts o las cabeceras HTTP de la página de pago. Entre ambos, el 6.4.3 y el 11.6.1 exigen tanto un inventario estático con controles de integridad como una capacidad de monitorización en vivo.
Paso 1: inventaría cada script de tus páginas de pago
Empieza con una auditoría completa de cada script que se carga en la página de pago. Esa lista incluye:
- Scripts propios que controla tu equipo
- Etiquetas de terceros cargadas mediante gestores de etiquetas (Google Tag Manager, Tealium, Segment)
- Píxeles de analítica (Google Analytics, Meta Pixel, cualquier etiqueta de atribución de marketing)
- Widgets de chat y soporte (Intercom, Drift, Zendesk)
- Scripts de test A/B y personalización
- Herramientas de detección de fraude
- Cualquier librería cargada desde un CDN
A la mayoría de los equipos les sorprende cuántos scripts se ejecutan de verdad en las páginas de pago. Los gestores de etiquetas suelen ser los culpables, ya que cargan scripts adicionales que nunca pasaron por una revisión de seguridad. Una herramienta de monitorización que descubre y lista cada script presente es la forma más rápida de construir un inventario preciso.
Paso 2: autoriza y justifica cada script
Para cada script del inventario, registra:
- Quién autorizó el script en esta página
- El propósito de negocio al que sirve
- Si la página de pago es el ámbito adecuado para él (muchos scripts de analítica no necesitan ejecutarse en las páginas de pago y deberían excluirse)
Cualquier script que no pueda aportar una justificación de negocio clara debería retirarse de la página de pago. Menos scripts significa una carga de cumplimiento menor y una superficie de ataque más pequeña.
Paso 3: implementa controles de integridad
Para cada script autorizado, pon en marcha un mecanismo de integridad. Tus opciones:
Subresource Integrity (SRI). Para los scripts cargados desde URLs externas, un hash SRI en la etiqueta del script le dice al navegador que rechace el script si su contenido ha cambiado. SRI funciona bien con los scripts servidos desde URLs de CDN estables y versionadas. No ayuda con los scripts cargados dinámicamente, los scripts cuyo contenido cambia sin que cambie la URL ni los scripts inline.
Content Security Policy. Una allowlist de CSP impide que se carguen scripts no autorizados. No detecta los cambios de comportamiento en un script que ya está en la allowlist.
Monitorización de integridad en tiempo de ejecución. Una herramienta que vigila el comportamiento de los scripts en tiempo real detecta el caso en el que un script autorizado empieza a hacer algo nuevo, como leer un campo de formulario que nunca había tocado o llamar a un endpoint que nunca había llamado. Ese cambio de comportamiento es el vector de Magecart, y es el que SRI y CSP no ven.
Para una cobertura completa del 6.4.3 y el 11.6.1, la monitorización en tiempo de ejecución es la capa que hace el trabajo. SRI y CSP son controles fundacionales que se sitúan por debajo.
Cómo cside cumple tanto el 6.4.3 como el 11.6.1
cside PCI Shield usa una sola etiqueta de script en la página de pago y luego:
- Descubre e inventaría cada script presente, con actualización continua
- Vigila el comportamiento de cada script en tiempo real y avisa cuando ese comportamiento cambia
- Produce las evidencias que necesita una evaluación PCI: un inventario de scripts con su estado de autorización, más eventos de detección de manipulaciones con marcas de tiempo
cside está validado por VikingCloud para los Requisitos 6.4.3 y 11.6.1 de PCI DSS 4.0.1. Esa validación significa que un asesor de seguridad cualificado ha revisado la herramienta y ha confirmado que cumple los requisitos de evidencia concretos de ambos controles, no solo su intención general.
Más lecturas
- cside PCI Shield: inventario continuo de scripts y monitorización en tiempo de ejecución para páginas de pago
- Por qué los crawlers no pueden ayudar con el cumplimiento de PCI (por sí solos)
- Por qué CSP no funciona
- Resumen del cumplimiento de PCI DSS
