Scripts de terceros en la página de pago: qué exige el PCI DSS

Cada script que se ejecuta en la página de pago (chat, analítica, gestor de etiquetas, reseñas, píxeles de marketing) puede, en principio, ver lo que escribe el cliente. Por eso el PCI DSS exige, en el requisito 6.4.3, un inventario de todos esos scripts con su justificación, un método para autorizar cada uno y otro para asegurar que no fueron alterados; y, en el 11.6.1, un mecanismo que detecte cambios en la página tal como la recibe el cliente y alerte al equipo, al menos una vez por semana. Ambas reglas son obligatorias desde el 31 de marzo de 2025.

Por qué los scripts de terceros son el eslabón débil

Un script de terceros no vive en tu servidor: el navegador del cliente lo descarga del servidor del proveedor en cada visita. Si ese proveedor es atacado o cambia el archivo, tu página cambia con él, sin que tu equipo haya publicado nada. La guía del PCI Security Standards Council sobre seguridad de la página de pago, de marzo de 2025, recuerda además que estos scripts pueden cargar otros, de socios del socio, y menciona herramientas de analítica, marketing, gestión de etiquetas, validación de formularios e incluso de pago entre las que pueden manipularse para capturar datos.

Un caso de estudio de Visa muestra el efecto multiplicador. La investigación empezó con el aviso de un banco sobre un solo restaurante, pero el código malicioso estaba en un archivo legítimo alojado por el proveedor de pedidos online, no en el sitio del restaurante. Muchos de los más de 1.500 clientes del proveedor usaban ese mismo archivo, y un tercio de ellos resultó comprometido. Visa dio con el origen diez días después de la infección.

Qué pide el PCI DSS, en lenguaje simple

Requisito 6.4.3: inventario, autorización e integridad

Todo script que se carga y ejecuta en el navegador del cliente en la página de pago necesita tres cosas:

• Autorización: un método para confirmar que cada script fue aprobado. La norma no dice cómo ni quién; según la guía del PCI SSC, la aprobación puede darse antes de añadir o modificar el script, o lo antes posible después, ya que el proveedor puede cambiar el archivo sin avisar.
• Integridad: un método para asegurar que el script no contiene nada no autorizado, al incorporarlo y en cada actualización.
• Inventario: la lista de todos los scripts, con la justificación técnica o de negocio de cada uno. En entornos sencillos, dice la guía, una hoja de cálculo puede bastar.

Los scripts de autenticación 3-D Secure están exentos de esta validación. Y un proveedor cuyos scripts no tienen relación con el pago puede no considerarse proveedor de servicios para otros fines de la norma, pero sus scripts siguen sujetos al 6.4.3 y al 11.6.1.

Requisito 11.6.1: detectar cambios

Hace falta un mecanismo que avise al equipo de cambios no autorizados (scripts que aparecen, cambian o desaparecen, y cambios en las cabeceras de seguridad) en la página tal como la recibe el navegador del cliente. Debe ejecutarse al menos una vez por semana o con la frecuencia que fije un análisis de riesgo. El propio PCI SSC recomienda una vigilancia frecuente o en tiempo real cuando sea posible, porque un cambio malicioso puede actuar sin ser visto entre una revisión y otra.

Cómo armar el inventario en la práctica

1. Mapea las páginas. Incluye la que muestra el formulario del proveedor de pagos. En sitios de una sola página, donde el navegador no recarga entre pasos, los scripts cargados antes siguen activos en el pago, y la guía considera todas las vistas dentro del alcance.
2. Lista lo que recibe el navegador, no solo lo que está en tu código: abre la página como cliente, porque los gestores de etiquetas agregan scripts sobre la marcha.
3. Documenta cada script: dirección de origen, proveedor, responsable interno, finalidad, justificación, quién lo autorizó y cuándo.
4. Decide: se queda, se va o se mueve a otra página. Sin justificación, no hay script.
5. Elige cómo asegurar la integridad: una lista de orígenes permitidos, la verificación de la huella del archivo o una herramienta especializada. El PCI DSS no impone un método.
6. Registra el comportamiento esperado: qué campos necesita leer el script y adónde envía datos.
7. Revisa ante cada cambio, incluidos los que el proveedor hace por su cuenta.

Qué puede salir mal

• La hoja de cálculo envejece. Un inventario que nadie actualiza se vuelve una foto vieja de la página.
• Aprobar al proveedor, no la versión. El archivo cambia en su servidor y la aprobación anterior no cubre el código nuevo.
• Olvidar la página que rodea al formulario. Usar el formulario del proveedor reduce el alcance, pero la página que lo muestra sigue siendo tu responsabilidad.
• Alertas sin responsable. Si el mecanismo solo alerta y no bloquea, el PCI SSC subraya que la respuesta debe ser rápida; define quién recibe y quién actúa.
• Tomar el mínimo como meta. Una revisión semanal deja días de exposición.

Proteside genera esa evidencia mientras protege: registra los scripts autorizados en la página de pago, verifica en el navegador del comprador qué cambia y adónde van los datos, y bloquea lo que no debería estar ahí. Mira cómo funcionan la solución de cumplimiento PCI DSS y la protección para pagos con tarjeta, y pruébalo gratis durante 14 días.