Cómo monitorear cambios en el checkout: qué vigilar y cuándo

Monitorear cambios en el checkout es saber, a tiempo para actuar, cuándo algo en la página de pago empezó a funcionar de una forma que la tienda no autorizó. Eso incluye los archivos en el servidor, los scripts que carga la página, los encabezados de seguridad y, sobre todo, lo que aparece en la pantalla de quien compra. Cada capa pide un método diferente, y ningún método ve las cuatro.

Por qué monitorear la página de pago y no solo el sitio

El checkout es la única página en la que un ataque se convierte en dinero en el momento. Un código que copia la tarjeta o cambia el QR del Pix (el sistema de pagos instantáneos del Banco Central do Brasil) solo necesita funcionar ahí, y por eso suele quedar apagado en el resto del sitio. En septiembre de 2026, las tiendas brasileñas afectadas por un código de este tipo vieron primero un síntoma comercial, el aumento de abandonos en el Pix, antes que cualquier alerta técnica.

Monitorear la página de pago también es una exigencia. Desde el 31 de marzo de 2025, el requisito 11.6.1 de PCI DSS pide un mecanismo que detecte cambios no autorizados en el contenido de la página y en los encabezados de seguridad, con una verificación al menos semanal o con la frecuencia que defina un análisis de riesgos de la propia empresa.

Qué vigilar: las cuatro capas

1. Archivos en el servidor

Los archivos de la plataforma, del tema y de los plugins. Un cambio fuera de una publicación planificada es la señal más clásica de una intrusión.

Lo que esta capa no ve: el código que llega desde una dirección externa y solo existe en el navegador.

2. Scripts que carga la página

La lista de todo lo que trae la página de pago: archivos propios, herramientas de análisis, chat, píxel de anuncios, scripts del proveedor de pago. Es el inventario que pide el requisito 6.4.3 de PCI DSS, con un responsable, un motivo y una garantía de integridad para cada elemento.

Lo que esta capa no ve: un script ya autorizado que cambia su comportamiento sin cambiar de nombre, o una extensión en el navegador del cliente.

3. Encabezados de seguridad

Las instrucciones que el servidor envía al navegador junto con la página, como la política que define desde dónde se pueden cargar scripts y a dónde se pueden enviar datos. Si alguien afloja esa política, la puerta queda abierta sin que cambie ningún archivo.

Lo que esta capa no ve: un ataque que usa un servicio ya autorizado. En junio de 2026, unos investigadores describieron un código de robo de tarjetas que usaba un servicio de pago conocido como punto de apoyo, justamente para pasar políticas que confiaban en él.

4. Lo que muestra la pantalla del cliente

El QR del Pix, el texto del Pix Copia e Cola (el código de pago en texto que el cliente copia y pega en la app de su banco), la línea digitable (el número del boleto) del boleto (boleto bancario brasileño), la dirección de la billetera, el formulario que recibe la tarjeta de crédito y la tarjeta de débito, y a dónde envía los datos ese formulario. Es aquí donde ocurre la estafa y es aquí donde aparece completa.

Lo que pide esta capa: comparar lo que está en pantalla con lo que emitió la tienda, y no solo registrar que algo cambió.

Con qué frecuencia

No existe una frecuencia única. La regla práctica es definir una por capa:

• Archivos en el servidor: en cada publicación y a diario, con una alerta inmediata para cualquier cambio fuera de una publicación.
• Scripts y encabezados: de forma continua, con una revisión humana al menos semanal, que es el mínimo del 11.6.1.
• Pantalla del cliente: en cada carga de la página de pago. Un QR cambiado el martes a las 10:00 ya recibió dinero a las 10:01.

Los métodos y lo que ve cada uno

• Monitoreo de archivos en el servidor. Bueno para intrusiones que tocan el código de la tienda. Ciego para lo que se arma en el navegador.
• Escaneo externo con un robot. Un robot abre el checkout cada cierto tiempo y registra lo que carga la página. Ayuda a armar el inventario, pero solo ve la sesión del robot, y los códigos maliciosos pueden comportarse distinto con visitantes que parecen automáticos.
• Informes del navegador sobre la política de seguridad. El navegador del cliente avisa cuando algo intentó cargarse desde donde no debía. Muestra los intentos bloqueados, no lo que pasó por una dirección autorizada.
• Script de monitoreo en la propia página. Corre en el navegador del cliente real y ve lo que la página realmente cargó y cambió después de abrirse.
• Verificación del dato de pago. Un paso más allá del anterior: además de ver que el QR cambió, lo compara con el QR que emitió la tienda y bloquea si no coincide.

Los tres primeros métodos dicen "algo cambió". Solo el último dice "el cliente está a punto de pagarle a la persona equivocada".

Cómo armar alertas que alguien atienda

1. Define qué está autorizado. Sin una lista de scripts y de destinos esperados, toda alerta es ruido.
2. Separa lo urgente de lo rutinario. Un script nuevo en la página de pago y un QR que no coincide son urgentes. El cambio de versión de una herramienta de análisis es rutina para revisar durante la semana.
3. Envía lo urgente a quien puede actuar. Un canal con guardia, no una bandeja de correo.
4. Junta las señales técnicas y las comerciales. La tasa de Pix pendientes, el abandono en el checkout y los reclamos de pagos sin pedido cuentan tanto como una alerta de archivo.
5. Guarda la evidencia. Fecha, página, qué cambió y quién lo aprobó. Es lo que pide el auditor de PCI DSS y lo que ayuda a la hora de explicarle el incidente al cliente.

Lista de control rápida

• Lista de scripts de la página de pago, con responsable y motivo.
• Alerta para archivos modificados fuera de una publicación.
• Política de seguridad de contenido con informes activos.
• Monitoreo en el navegador del cliente real, no solo con un robot.
• Verificación del QR, del Copia e Cola, de la línea digitable y del formulario de tarjeta contra lo que emitió la tienda.
• Panel diario con la tasa de Pix pendientes.
• Registro de cada cambio aprobado y de cada alerta atendida.

Para el contexto de los ataques que este monitoreo evita, lee Magecart: qué es y cómo proteger tu tienda online. Para los requisitos, consulta scripts de terceros en la página de pago.

Dónde entra Proteside

Proteside cubre la segunda y la cuarta capa en el navegador de quien compra: mantiene el inventario de scripts de la página de pago y verifica, en cada pedido, que el QR, el Copia e Cola, la línea digitable y el formulario de tarjeta sean los que emitió la tienda. Cuando no lo son, bloquea el cambio antes de la confirmación, avisa a la tienda y registra el caso como evidencia para PCI DSS. Conoce cómo funciona.