PCI DSS 4.0: los requisitos 6.4.3 y 11.6.1 para scripts en el checkout

Aviso: este texto explica el estándar PCI DSS y las publicaciones oficiales del PCI Security Standards Council. No es un dictamen de cumplimiento ni sustituye al asesor calificado (QSA) ni al adquirente.

PCI DSS v4.0.1 tiene dos requisitos para el JavaScript que se ejecuta en la página de pago de una tienda en línea. El 6.4.3 pide que cada script de esa página esté autorizado, tenga la integridad verificada y figure en un inventario con justificación. El 11.6.1 pide un mecanismo que detecte y avise de cambios no autorizados en las cabeceras HTTP que afectan a la seguridad y en el contenido de los scripts de la página, tal como los recibe el navegador del cliente, al menos una vez por semana o con la frecuencia definida en un análisis de riesgo. Los dos dejaron de ser buena práctica y pasaron a ser obligatorios el 31 de marzo de 2025. Para el comercio que valida con el SAQ A, el PCI SSC sustituyó en 2025 los dos requisitos por un criterio de elegibilidad sobre ataques de script.

El alcance de este texto es PCI DSS v4.0.1 (junio de 2024), la versión vigente que pude confirmar en octubre de 2026, y las publicaciones del PCI SSC sobre el SAQ A de enero y febrero de 2025. Las citas del estándar son traducciones libres; el texto que vale es el original en inglés, en la biblioteca de documentos del PCI SSC. Para el contexto más amplio de seguridad del sitio, consulta la guía de seguridad básica de un sitio web.

Por qué existen estos requisitos

Una página de pago suele cargar scripts de varios orígenes: el propio sitio, bibliotecas en CDN, analítica, gestores de etiquetas. La guía del 6.4.3 explica que scripts en apariencia inofensivos pueden usarse para cargar código malicioso que lee los datos de la tarjeta en el navegador del cliente y los envía fuera. Este ataque se llama e-skimming. El 11.6.1 parte de la misma premisa y añade que, como las páginas se montan en el navegador a partir de varias fuentes, el único lugar donde se puede notar la alteración es la página tal como la recibe el navegador (PCI DSS v4.0.1, requisitos 6.4.3 y 11.6.1, columnas de orientación).

Versiones y fechas

Sobre la fecha de entrada en vigor del nuevo SAQ A hay una pequeña discrepancia entre los textos del PCI SSC: el anuncio de enero habla del 31 de marzo de 2025, y la entrada de febrero sobre la FAQ habla del 1 de abril de 2025.

El requisito 6.4.3: autorización, integridad e inventario

Todos los scripts que se cargan y ejecutan en el navegador del cliente en la página de pago tienen que gestionarse así (PCI DSS v4.0.1, requisito 6.4.3, traducción libre):

• hay un método para confirmar que cada script está autorizado;

• hay un método para asegurar la integridad de cada script;

• hay un inventario de todos los scripts, con una justificación escrita, de negocio o técnica, de por qué cada uno es necesario.

Las notas de aplicabilidad y la guía añaden puntos prácticos:

• El requisito se aplica a los scripts del propio entorno y a los scripts de terceros y de "cuartos" (los que carga un script de terceros).

• Si tu página incrusta el formulario de pago de un proveedor (por ejemplo, en un iframe), el requisito se aplica a los scripts de tu página. Los scripts de dentro del formulario del proveedor son responsabilidad suya, y la guía dice que el comercio debe esperar del proveedor la evidencia de que cumple el requisito.

• La autorización puede ser manual o mediante un flujo automatizado. Cuando no sea viable autorizar un script antes de que cambie, la autorización debe confirmarse lo antes posible después del cambio.

• Los ejemplos de mecanismo de integridad que se citan son SRI, CSP y sistemas de gestión de scripts o etiquetas que impidan la ejecución de código malicioso. La lista no es cerrada.

• Para páginas de pago cargadas en un iframe, la guía sugiere usar la CSP de la página principal para restringir desde dónde puede cargarse el iframe.

En la revisión 4.0.1, el PCI SSC aclaró que la justificación del inventario puede ser de negocio o técnica, e incluyó las tres notas sobre iframes y la indicación de autorizar después del cambio cuando no se pueda autorizar antes (Summary of Changes de v4.0 a v4.0.1, agosto de 2024).

El requisito 11.6.1: detección de cambios y manipulación

El 11.6.1 pide un mecanismo de detección de cambios y manipulación que (PCI DSS v4.0.1, requisito 11.6.1, traducción libre):

• avise al personal de modificaciones no autorizadas, incluidos indicadores de compromiso, cambios, adiciones y eliminaciones, en las cabeceras HTTP que afectan a la seguridad y en el contenido de los scripts de las páginas de pago, tal como los recibe el navegador del cliente;

• evalúe las cabeceras y la página tal como se reciben;

• se ejecute al menos una vez por semana, o con la frecuencia definida en el análisis de riesgo específico de la empresa, hecho según el requisito 12.3.1.

La versión 4.0 hablaba de "cabeceras HTTP y contenido de las páginas" y de "una vez cada siete días". La 4.0.1 restringió el objetivo a las cabeceras que afectan a la seguridad y al contenido de los scripts, y cambió el plazo por "semanal" (Summary of Changes de v4.0 a v4.0.1). El estándar no enumera cuáles son esas cabeceras; la CSP es el caso más evidente, porque la propia guía dice que un cambio en la CSP puede indicar manipulación.

Las notas de aplicabilidad dejan claro que la intención no es instalar software en el ordenador o en el navegador del cliente, sino usar técnicas como las de los ejemplos. Los ejemplos de la guía, que pueden combinarse (PCI DSS v4.0.1, 11.6.1):

• informes de infracción de la CSP enviados con las directivas report-to o report-uri;

• vigilar los cambios en la propia CSP;

• monitorización externa con sistemas que piden y analizan las páginas (monitorización sintética) y avisan de cambios en el JavaScript;

• un script de detección, resistente a la manipulación, incrustado en la página, que avisa y bloquea el comportamiento malicioso;

• proxies inversos y CDN que detectan cambios en los scripts.

El estándar advierte que esta lista no es completa y que ninguno de estos mecanismos, por sí solo, es necesariamente una solución completa de detección y alerta.

A quién se aplica

PCI DSS se aplica a todas las entidades que almacenan, procesan o transmiten datos de tarjeta, o que pueden afectar a la seguridad de esos datos: comercios, procesadores, adquirentes, emisores y otros proveedores. Quién tiene que validar el cumplimiento, y de qué forma, lo deciden quienes administran los programas de cumplimiento, como las marcas de tarjetas y los adquirentes (PCI DSS v4.0.1, introducción). La tabla resume cómo encajan los dos requisitos en cada forma de integrar el pago, según el estándar y la FAQ 1588. Qué cuestionario (SAQ) o informe corresponde a tu caso se define con el adquirente.

Qué cambió en el SAQ A en 2025

El SAQ A es el cuestionario de autoevaluación más corto, el que usan los comercios que externalizan todo el tratamiento de los datos de tarjeta. En enero de 2025 el PCI SSC anunció una nueva versión del SAQ A para PCI DSS v4.0.1 que (PCI SSC, 30/01/2025):

• quitó del cuestionario los requisitos 6.4.3 y 11.6.1, además del 12.3.1, el análisis de riesgo que respalda el 11.6.1;

• añadió un criterio de elegibilidad: el comercio confirma que su sitio no es susceptible a ataques de scripts que puedan afectar a sus sistemas de comercio electrónico.

El propio Consejo deja claro que el cambio afecta solo a la forma de reportar en el SAQ A, y que no elimina los requisitos del estándar. En palabras del anuncio, los cambios "do not remove or diminish the underlying requirements within PCI DSS".

La FAQ 1588, de febrero de 2025, explica cómo cumplir el criterio (FAQ 1588; entrada del PCI SSC sobre la FAQ):

• El criterio se aplica a los comercios cuya página incrusta el formulario de pago de un proveedor, por ejemplo en un iframe. No se aplica a quien redirige al cliente al proveedor ni a quien externaliza todo el pago.

• Hay dos caminos: usar técnicas como las de los requisitos 6.4.3 y 11.6.1, aplicadas por el propio comercio o por un tercero; u obtener del proveedor de pago, que tiene que cumplir PCI DSS, la confirmación de que su solución, implementada según sus instrucciones, protege la página del comercio contra ataques de script.

• Un proveedor de scripts que no tienen relación con el pago y no pueden afectar a la seguridad de los datos de tarjeta no se considera proveedor de servicios (TPSP) a efectos del SAQ A.

• El comercio debe confirmar con el adquirente o con las marcas de tarjetas si tiene que enviar un SAQ y cuál.

Quien valida con otros cuestionarios o con un informe de asesor sigue respondiendo por los dos requisitos. En el SAQ A-EP de la versión 4.0, por ejemplo, el 6.4.3 y el 11.6.1 aparecen con las mismas exigencias (SAQ A-EP v4.0). Comprueba la versión vigente del cuestionario en la biblioteca de documentos del PCI SSC antes de responder.

Cómo implementarlo en la práctica

Los pasos de abajo son una recomendación para organizar el trabajo, basada en los ejemplos del propio estándar. No son un procedimiento oficial del PCI SSC, y la forma de evidenciar cada punto hay que acordarla con el asesor.

1. Identifica las páginas de pago: la página con el formulario de tarjeta y, si el formulario es de un proveedor en un iframe, la página del comercio que lo incrusta. Incluye las variantes (móvil, idiomas, pruebas A/B).

2. Arma el inventario. Para cada script: dirección, origen (propio, de terceros, cargado por un tercero), finalidad, justificación, responsable interno y fecha de aprobación. Los scripts sin justificación salen de la página.

3. Define el proceso de autorización. Puede ser un punto de la revisión de código o un flujo de aprobación en el gestor de etiquetas. Para los scripts que el proveedor cambia sin aviso, registra la confirmación justo después del cambio, como admite la guía.

4. Aplica controles de integridad. SRI (atributo integrity) sirve para archivos estáticos y versionados: el navegador rechaza el archivo si su contenido cambia (MDN: SRI). Para el resto, una CSP limita de dónde carga scripts la página y adónde puede enviar datos, y la directiva frame-src limita de dónde puede venir el iframe de pago. Los detalles están en el artículo sobre cabeceras HTTP de seguridad.

5. Implanta la detección del 11.6.1: informes de infracción de la CSP, comparación periódica de las cabeceras y los scripts recibidos con la versión aprobada, u otro mecanismo de la lista del estándar. Si la frecuencia es menor que semanal o distinta, documenta el análisis de riesgo del 12.3.1.

6. Define quién recibe las alertas y qué hacer con ellas: confirmar si el cambio estaba autorizado, actualizar el inventario o activar el plan de respuesta a incidentes.

7. Guarda las evidencias: inventario con historial, aprobaciones, configuración de los mecanismos y registros de las alertas atendidas.

Un ejemplo de CSP para la página del comercio que incrusta el formulario de un proveedor. Los dominios son ficticios; usa los que documente tu proveedor.

Content-Security-Policy:
  script-src 'nonce-{generado por respuesta}' 'strict-dynamic';
  frame-src https://pago.proveedor.ejemplo;
  connect-src 'self' https://api.proveedor.ejemplo;
  form-action 'self' https://pago.proveedor.ejemplo;
  object-src 'none';
  base-uri 'none';
  report-to csp

Con esta política, el navegador solo ejecuta scripts con el nonce de la respuesta (y los que estos carguen), solo abre el iframe de pago en el dominio del proveedor, solo hace llamadas de red al propio sitio y a la API del proveedor, y reporta las infracciones. En tiendas con muchos scripts de marketing, el connect-src restringido suele ser lo que más ajustes exige.

Límites de cada control

• SRI no funciona con scripts que el proveedor actualiza en la misma dirección: con cada actualización legítima, el hash deja de coincidir y el navegador bloquea el archivo.

• Una CSP con lista de dominios permite cualquier código que venga de un dominio permitido. Si el proveedor permitido sufre un ataque, la política no lo impide.

• La monitorización externa ve la página que recibió el robot. El contenido que cambia según el país, el dispositivo, la cookie o la hora puede no aparecer en la verificación.

• El estándar acepta una revisión semanal, pero un ataque puede estar activo entre una revisión y la siguiente. El análisis de riesgo del 12.3.1 sirve precisamente para decidir si la página necesita más frecuencia.

• Cumplir el 6.4.3 y el 11.6.1 no hace que el resto del entorno cumpla PCI DSS, y una herramienta no sustituye la evaluación del asesor ni la aceptación del adquirente.

Cómo verificar tu sitio

Para empezar a mano, abre la página de pago con DevTools, filtra la pestaña Network por JS y apunta cada script, su origen y quién lo pidió (la columna Initiator lo muestra). Después revisa las cabeceras de la respuesta con curl -sI y mira si hay CSP.

Los planes de pago de WebVyze incluyen un inventario de los scripts de las páginas de checkout ligado a los requisitos 6.4.3 y 11.6.1, además de auditorías programadas y alertas. WebVyze solo lee páginas públicas y nunca modifica el sitio, así que muestra lo que recibe un visitante y no ve lo que hay dentro del iframe del proveedor ni tus procesos internos de aprobación. Ayuda a reunir y mantener las evidencias; no certifica el cumplimiento de PCI DSS.