El PCI SSC ha publicado un nuevo suplemento informativo (Information Supplement) orientado a la seguridad en páginas de pago y prevención de ataques de e-skimming como guÃa para la implementación de los controles 6.4.3 y 11.6.1 de PCI DSS v4.0.
En marzo de 2025 el PCI SSC publicó el documento Information Supplement: Payment Page Security and Preventing E-Skimming – Guidance for PCI DSS Requirements 6.4.3 and 11.6.1 en donde explica en mayor detalle los controles para la protección ante ataques de e-skimming. Este documento es el resultado del trabajo de las fuerzas de tarea de Comercio Electrónico (E-Commerce Guidance Task Force) y pequeños y medianos negocios (Small Merchant Business Task Force), con el soporte de otros equipos como el Global Executive Assessor Roundtable (GEAR). La necesidad de tener este suplemento informativo surgió de la cantidad de dudas generadas tras la inclusión de los controles 6.4.3 y 11.6.1 en la versión de PCI DSS v4.0, cuya entrada en vigor será este 1 de abril de 2025.
Contenido y organización de este suplemento informativo
Como ya lo habÃamos adelantado en PCI Hispano en el artÃculo «Implementación de controles contra e-skimming (PCI DSS req. 6.4.3 y 11.6.1)«, la protección contra ataques de e-skimming se puede implementar empleando diferentes estrategias, pero es muy importante que se cubran todos los elementos requeridos por los requisitos 6.4.3 y 11.6.1:
6.4.3 All payment page scripts that are loaded and executed in the consumer’s browser are managed as follows:
• A method is implemented to confirm that each script is authorized.
• A method is implemented to assure the integrity of each script.
• An inventory of all scripts is maintained with written business or technical justification as to why each is necessary.
• A method is implemented to confirm that each script is authorized.
• A method is implemented to assure the integrity of each script.
• An inventory of all scripts is maintained with written business or technical justification as to why each is necessary.
11.6.1 A change- and tamper-detection mechanism is deployed as follows:
• To alert personnel to unauthorized modification (including indicators of compromise, changes, additions, and deletions) to the security-impacting HTTP headers and the script contents of payment pages as received by the consumer browser.
• The mechanism is configured to evaluate the received HTTP headers and payment pages.
• The mechanism functions are performed as follows:
– At least weekly
OR
– Periodically (at the frequency defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1).
• To alert personnel to unauthorized modification (including indicators of compromise, changes, additions, and deletions) to the security-impacting HTTP headers and the script contents of payment pages as received by the consumer browser.
• The mechanism is configured to evaluate the received HTTP headers and payment pages.
• The mechanism functions are performed as follows:
– At least weekly
OR
– Periodically (at the frequency defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1).
TerminologÃa
Uno de los valores que aporta este nuevo documento es la aclaración de conceptos y terminologÃa. Por fin se indican las diferencias entre una página que no es de pago (cualquier página que incrusta una página de pago y los campos de su formulario), una página de pago (una página que puede contener uno o más elementos de un formulario destinado a capturar datos de cuenta o a enviar esos datos capturados para procesamiento o autorización de la transacción) y un formulario de pago (formulario con los campos empleados para capturar los datos de cuenta del titular de tarjeta). Igualmente, se define lo que es un script de una página de pago (componentes JavaScript, VB Script o WASM interpretados por el navegador del cliente que pueden ser usados para publicidad, selección de productos o seguridad), aclarando que componentes HTML o CSS no pueden ser catalogados como tales (al no ser lenguajes de programación).
Descripción gráfica de una página de pago y sus componentes. Fuente: John Elliot – https://pcirocks.substack.com/p/what-exactly-is-a-payment-page
Uso de iframes en una página de pago. Nótese la similitud de este gráfico del suplemento informativo con la publicada por John Elliot
Igualmente, se listan algunos ejemplos de encabezados HTTP que pueden impactar la seguridad de una página de pago y que deben ser configurados/monitorizados:
- Content Security Policy (CSP)
- X-Frame-Options (protection against clickjacking)
- Strict Transport Security (HSTS)
- X-XSS-Protection (XSS Filter)
- X-Content-Type-Options (prevent MIME sniffing)
- Set-Cookie
Scripts
Se aclara que los scripts pueden ser cargados desde un servidor controlado por la entidad (first-party servers) o desde un tercero (third-party servers) que, a su vez, pueden cargarlos desde otros proveedores (four-party servers).
Por otro lado, se explican los dos tipos de ataques que pueden comprometer contenido activo: ataques de cadena de suministro (en donde el atacante compromete scripts de terceros que son cargados en la página del comercio) o ataques de inyección de scripts (en donde el atacante inyecta scripts modificados y no autorizados en la página de pago para exfiltrar datos sensibles).
Una vez el script es inyectado, puede funcionar de manera silenciosa (capturando los datos de forma encubierta sin levantar sospechas) o pidiendo el ingreso de los datos dos veces (una en donde el script captura los datos y los exfiltra y otra en donde se vuelven a capturar para enviarlos al flujo normal de operación).
Escenarios de páginas de pago
Esta sección nos recuerda aquel famoso documento de Visa del 2014 (Processing e-commerce payments) en donde se categorizaban los distintos escenarios de páginas de pago. Pues bien: en 2025 esto no ha cambiado mucho y la categorización sigue siendo similar:
- Formularios de pago alojados por el comercio, incluyendo Merchant-Posted Payment y Direct-Post Payment.
- Formularios de pago incrustados (iframes)
- Redirección
- Delegación completa (fully outsource)
Con base en esta categorización se establecen las responsabilidades de implementación de controles por parte del comercio y de sus proveedores:
Aplicabilidad y responsabilidad de los controles 6.4.3 y 11.6.1
Igualmente, se incluyen aclaraciones adicionales relacionadas con los criterios de aplicabilidad del SAQ A de PCI DSS que ya se discutieron en PCI Hispano (Cambios en el SAQ A de PCI DSS v4.0.1).
Mejores prácticas para minimizar los riesgos del uso de scripts de terceros
Esta documento también incluye un listado de mejores prácticas para minimizar el riesgo en el uso de scripts provistos por terceros, entro las que se encuentran:
- Minimizar el número de scripts al estrictamente necesario
- Mover los scripts a iframes aislados
- Limitar las fuentes de scripts
- Entender el comportamiento de los scripts, y
- Ejecutar validaciones técnicas de seguridad de forma periódica o continua (revisión de código, análisis de comportamiento y/o monitorización en tiempo de ejecución)
Controles y técnicas para cumplir con los requerimientos 6.4.3 y 11.6.1
Como ya se habÃa avanzado en PCI Hispano, existen varias técnicas para implementar los controles de seguridad exigidos en estos requisitos.
- Content Security Policy (CSP) y Sub-resource Integrity (SRI)
- Monitorización de páginas web sin agentes (agentless) o con agentes
- Uso de proxies
Evidencia de cumplimiento y mejores prácticas
Y para terminar, el documento incluye una serie de mejores prácticas para proveedores de servicio y comercios asà como una guÃa para asesores y entidades acerca de la evidencia necesaria para demostrar la correcta implementación de los controles.
Conclusión
Este suplemento informativo era algo que se venÃa esperando desde hacÃa mucho tiempo. Los requisitos 6.4.3 y 11.6.1, al ser nuevos en PCI DSS, no contaban con suficiente documentación y experiencia en implementación como sà sucede con otros controles más «tradicionales» como las soluciones antimalware, firewalls, sistemas de detección/prevención de intrusos o monitorización de integridad de ficheros. Por esa razón, las indicaciones, sugerencias y mejores prácticas en la industria, centralizadas por el PCI SSC en estos documentos, se convierten en una herramienta indispensable para evitar problemas derivados de malas interpretaciones de los controles o implementación parcial de soluciones que pueden llevar a una falsa sensación de seguridad y exponer a la entidad a incidentes.
Desde PCI Hispano recomendamos la lectura del artÃculo What exactly is a Payment Page? de John Elliot, probablemente una de las personas con mayor conocimiento en este campo, que explicó estos conceptos en 2023 y gran parte de su trabajo fue incluido en este nuevo suplemento informativo.
ES 
EN