El PCI SSC publicó una FAQ sobre la elegibilidad para empresas SAQ A en relación con los scripts presentes en sus sitios, haciendo referencia a los requisitos 6.4.3 y 11.6.1 de PCI DSS 4.0.1.
Esta actualización generó confusión tanto entre los evaluadores como entre nuestros clientes y prospectos.
SAQ A está destinado a comerciantes que externalizan completamente el procesamiento de pagos a proveedores de servicios de terceros validados por PCI DSS. Ningún dato de titulares de tarjetas debe ser procesado, almacenado ni transmitido a través de los sistemas del comerciante.
Un error frecuente es creer que usar un iframe o una redirección es suficiente. No lo es.
El requisito clave es que el comerciante no debe cargar scripts que interactúen con la página de pago. Si hay scripts del dominio del comerciante o de terceros, SAQ A no será aplicable.
El papel de los scripts en el cumplimiento de SAQ A
- El formulario de pago debe estar alojado y controlado íntegramente por un proveedor con cumplimiento PCI.
- El comerciante no puede cargar scripts que modifiquen, supervisen o interactúen con el formulario de pago de ninguna manera.
- Los únicos scripts permitidos son los gestionados directamente por el proveedor de pagos validado.
Si tu página de pago incluye JavaScript —ya sea para analítica, mejoras de interfaz o herramientas de terceros en general— es posible que no cumplas los requisitos para SAQ A. Aunque un script no toque los campos de pago, puede seguir introduciendo riesgos, como:
- Ataques de form-jacking que capturan la entrada del usuario antes de que llegue al proveedor de pagos.
- Modificaciones no autorizadas del DOM que afectan al proceso de pago.
- Ataques a la cadena de suministro que aprovechan scripts de terceros.
Una sola frase genera debate
El comerciante ha confirmado que su sitio no es susceptible a ataques de scripts que puedan afectar al sistema o sistemas de comercio electrónico del comerciante.
Esto se añadió en la actualización de enero relativa a las empresas SAQ A.
Aunque PCI DSS se aplica a los pagos y a las páginas de pago, esta frase establece claramente que el sitio completo no es susceptible a ataques de scripts. Tiene sentido. Por ejemplo, si un enlace que lleva a una página de pago no está protegido ni supervisado, un script JavaScript malicioso inyectado por un tercero puede redirigir ese enlace y comprometer igualmente al usuario.
Cómo debe hacerse eso no está claro, lo que genera confusión.
El PCI SSC indica que se consulte la versión más reciente de la lista PCI DSS SAQ A para obtener la lista completa de criterios de elegibilidad, pero esta no ofrece información específicamente vinculada a la cita anterior.
En la lista SAQ A, esta cita menciona directamente los scripts que se deben supervisar y/o proteger:
En 6.4.3 (página 7):
Todos los scripts de la página de pago que se cargan y ejecutan en el navegador del consumidor se gestionan de la siguiente manera: Se implementa un método para confirmar que cada script está autorizado. Se implementa un método para garantizar la integridad de cada script. Se mantiene un inventario de todos los scripts con una justificación escrita de por qué cada uno es necesario.
En esta sección se mencionan únicamente todos los scripts de la página de pago. Sin embargo, en las notas de aplicabilidad que figuran a continuación se indica:
Este requisito se aplica a todos los scripts cargados desde el entorno de la entidad y a los scripts cargados desde terceros y cuartos.
La expresión "entorno de la entidad" difumina los límites y abre la puerta a interpretar "su sitio" como un todo, tal como se usa en la frase que originó este debate.
Dado que los sitios cargan scripts de forma dinámica, un script de cualquier página puede persistir hasta el proceso de pago e interferir potencialmente con las transacciones. Los scripts de terceros, aunque no estén relacionados o se carguen en páginas anteriores a las de pago, pueden introducir vulnerabilidades.
En las aplicaciones de página única (SPAs), los scripts persisten entre vistas, lo que significa que un script cargado en cualquier página puede seguir activo durante el proceso de pago. De manera similar, en las aplicaciones web progresivas (PWAs), los scripts se ejecutan de forma continua mientras los usuarios navegan, lo que aumenta el riesgo de interacciones no deseadas con el flujo de pago.
En 11.6.1 (página 16), notas de aplicabilidad:
La intención de este requisito no es que una entidad instale software en los sistemas o navegadores de sus consumidores, sino que la entidad utilice técnicas como las descritas en los Ejemplos de la columna de Orientación de PCI DSS (de los Requisitos y Procedimientos de Prueba de PCI DSS) para prevenir y detectar actividades de scripts inesperadas.
Este camino nos lleva a esos ejemplos, que se encuentran en la lista SAQ A en la página vi. En la sección "No Aplicable" se indica:
El requisito no se aplica al entorno del comerciante. (Consulte "Orientación para Requisitos No Aplicables" a continuación para ver ejemplos.) Todas las respuestas en esta columna requieren una explicación de respaldo en el Apéndice D de este SAQ.
Solo se encuentra un ejemplo en "Orientación para Requisitos No Aplicables":
Los requisitos para proteger todos los medios con datos de titulares de tarjetas (Requisitos 9.4.1 - 9.4.6) solo se aplican si un comerciante almacena medios en papel con datos de titulares de tarjetas; si no se almacenan medios en papel, el comerciante puede seleccionar No Aplicable para esos requisitos.
El "Apéndice D" simplemente hace referencia a un área donde la empresa que solicita el estatus SAQ A, o los evaluadores que evalúan a estas empresas, pueden registrar sus hallazgos y conclusiones sobre este tema.
¿Cómo cumplir con los requisitos?
Además de todos los demás requisitos de SAQ A, las empresas deben demostrar que su sitio web está protegido contra ataques basados en scripts no autorizados. Cómo lo demuestran queda a criterio de cada uno. En cside creamos una herramienta que hace precisamente eso y permite a las empresas marcar la casilla de los requisitos 6.4.3 y 11.6.1. Sin embargo, dependiendo de la configuración del sitio web, existen otras formas, siempre que cumplan con los demás requisitos necesarios para ser elegibles para SAQ A.
¿Necesitas cumplir con 6.4.3 y 11.6.1?
Si eres elegible para SAQ A, técnicamente estás exento de los requisitos 6.4.3 y 11.6.1.
Sin embargo, la elegibilidad para SAQ A requiere que confirmes que tu sitio completo no es susceptible a ataques basados en scripts que puedan comprometer tu sistema de comercio electrónico. Aunque el PCI SSC no define explícitamente cómo validar esto, significa que debes garantizar que:
- No se ejecuten scripts no autorizados en tu sitio.
- Tu proceso de pago esté protegido contra manipulaciones (por ejemplo, secuestro de redirecciones).
- Supervises y protejas todas las integraciones de terceros.
Si no eres elegible para SAQ A, debes cumplir con los requisitos 6.4.3 y 11.6.1, ya que tu entorno cae en una categoría de cumplimiento superior que requiere controles de seguridad adicionales.
Y todo esto aplica al sitio completo, tal como establece la frase: "El comerciante ha confirmado que su sitio no es susceptible a ataques de scripts que puedan afectar al sistema o sistemas de comercio electrónico del comerciante."
Ejemplos que no califican (SAQ A no permitido)
- Proceso de pago personalizado con llamadas directas a la API de un procesador (se requiere SAQ D).
- Una página de pago que incluye scripts no protegidos que afectan a los campos de pago.
- Uso de campos alojados por terceros pero modificados mediante JavaScript.
- No confirmar que el sitio no es susceptible a ataques de scripts que puedan afectar a los sistemas de comercio electrónico del comerciante.
Conclusión
SAQ A ofrece una vía de cumplimiento simplificada para los comerciantes que pueden externalizar completamente el procesamiento de pagos, pero las últimas aclaraciones ponen de relieve un cambio fundamental: las responsabilidades de seguridad no se detienen en la página de pago.
Aunque 6.4.3 y 11.6.1 no se aplican a los comerciantes SAQ A, garantizar que todo el sitio esté protegido frente a ataques basados en scripts es ahora un requisito.
Esto significa que los comerciantes deben adoptar medidas de seguridad proactivas —no solo para mantener el cumplimiento, sino para prevenir amenazas que podrían comprometer su ecosistema de comercio electrónico. CSP, SRI y la supervisión de la integridad de scripts probablemente se conviertan en expectativas de referencia en lugar de salvaguardas opcionales.
Con cside cumples automáticamente con los requisitos 6.4.3 y 11.6.1.
Ayudamos a los comerciantes a detectar, supervisar y mitigar los riesgos basados en scripts. Si no estás seguro de tu nivel de cumplimiento, podemos ayudarte a marcar la casilla y mantenerte seguro.
Contáctanos para proteger tu entorno del lado del cliente y mantener el cumplimiento de SAQ A con total confianza.
