Como monitorar alterações no checkout: o que vigiar e quando

Monitorar alterações no checkout é saber, a tempo de agir, quando algo na página de pagamento passou a funcionar de um jeito que a loja não autorizou. Isso inclui os arquivos no servidor, os scripts que a página carrega, os cabeçalhos de segurança e, principalmente, o que aparece na tela de quem compra. Cada camada pede um método diferente, e nenhum método vê as quatro.

Por que monitorar a página de pagamento e não só o site

O checkout é a única página em que um ataque vira dinheiro na hora. Um código que copia o cartão ou troca o QR do Pix só precisa funcionar ali, e por isso costuma ficar desligado no resto do site. Em setembro de 2026, lojas brasileiras atingidas por um código desse tipo viram primeiro um sintoma comercial, o aumento de desistências no Pix, antes de qualquer alerta técnico.

Monitorar a página de pagamento também é exigência. Desde 31 de março de 2025, o requisito 11.6.1 do PCI DSS pede um mecanismo que detecte alterações não autorizadas no conteúdo da página e nos cabeçalhos de segurança, com verificação pelo menos semanal ou na frequência definida por uma análise de risco da própria empresa.

O que vigiar: as quatro camadas

1. Arquivos no servidor

Os arquivos da plataforma, do tema e dos plugins. Uma alteração fora de uma publicação planejada é o sinal mais clássico de invasão.

O que essa camada não vê: código que chega de um endereço externo e só existe no navegador.

2. Scripts carregados pela página

A lista de tudo o que a página de pagamento puxa: arquivos próprios, ferramentas de análise, chat, pixel de anúncio, scripts do provedor de pagamento. É o inventário que o requisito 6.4.3 do PCI DSS pede, com dono, motivo e garantia de integridade para cada item.

O que essa camada não vê: um script já autorizado que muda o comportamento sem mudar de nome, ou uma extensão no navegador do cliente.

3. Cabeçalhos de segurança

As instruções que o servidor manda ao navegador junto com a página, como a política que define de onde scripts podem ser carregados e para onde dados podem ser enviados. Se alguém afrouxa essa política, a porta fica aberta sem que nenhum arquivo mude.

O que essa camada não vê: um ataque que usa um serviço já liberado. Em junho de 2026, pesquisadores descreveram um código de roubo de cartão que usava um serviço de pagamento conhecido como ponto de apoio, justamente para passar por políticas que confiavam nele.

4. O que a tela do cliente mostra

O QR do Pix, o texto do Copia e Cola, a linha digitável do boleto, o endereço da carteira, o formulário que recebe o cartão de crédito e o cartão de débito, e para onde esse formulário envia os dados. É aqui que o golpe acontece e é aqui que ele aparece por inteiro.

O que essa camada pede: comparar o que está na tela com o que a loja emitiu, e não apenas registrar que algo mudou.

Com que frequência

Não existe uma frequência única. A regra prática é definir uma por camada:

• Arquivos no servidor: a cada publicação e diariamente, com alerta imediato para alteração fora de publicação.
• Scripts e cabeçalhos: contínuo, com revisão humana pelo menos semanal, que é o mínimo do 11.6.1.
• Tela do cliente: a cada carregamento da página de pagamento. Um QR trocado na terça às 10h já recebeu dinheiro às 10h01.

Métodos e o que cada um enxerga

• Monitoramento de arquivos no servidor. Bom para invasões que mexem no código da loja. Cego para o que é montado no navegador.
• Varredura externa por robô. Um robô abre o checkout de tempos em tempos e registra o que a página carrega. Ajuda a montar o inventário, mas vê só a sessão do robô, e códigos maliciosos podem se comportar de outra forma para visitantes que parecem automáticos.
• Relatórios do navegador sobre a política de segurança. O navegador do cliente avisa quando algo tentou carregar de onde não devia. Mostra tentativas bloqueadas, não o que passou por um endereço liberado.
• Script de monitoramento na própria página. Roda no navegador do cliente real e vê o que a página realmente carregou e mudou depois de abrir.
• Conferência do dado de pagamento. Um passo além do anterior: além de ver que o QR mudou, compara com o QR que a loja emitiu e bloqueia se não bater.

Os três primeiros métodos dizem "algo mudou". Só o último diz "o cliente está prestes a pagar a pessoa errada".

Como montar alertas que alguém atende

1. Defina o que é autorizado. Sem uma lista de scripts e de destinos esperados, todo alerta é ruído.
2. Separe o urgente do rotineiro. Script novo na página de pagamento e QR divergente são urgentes. Mudança de versão de uma ferramenta de análise é rotina para revisar na semana.
3. Mande o urgente para quem pode agir. Um canal com plantão, não uma caixa de e-mail.
4. Junte sinais técnicos e comerciais. Taxa de Pix pendente, abandono no checkout e reclamações de pagamento sem pedido contam tanto quanto um alerta de arquivo.
5. Guarde a evidência. Data, página, o que mudou e quem aprovou. É o que o auditor do PCI DSS pede e o que ajuda na hora de explicar o incidente ao cliente.

Checklist rápido

• Lista de scripts da página de pagamento, com dono e motivo.
• Alerta para arquivo alterado fora de publicação.
• Política de segurança de conteúdo com relatórios ativos.
• Monitoramento no navegador do cliente real, não só por robô.
• Conferência do QR, do Copia e Cola, da linha digitável e do formulário de cartão contra o que a loja emitiu.
• Painel diário com a taxa de Pix pendente.
• Registro de cada alteração aprovada e de cada alerta tratado.

Para o contexto dos ataques que esse monitoramento evita, leia Magecart: o que é e como proteger o e-commerce. Para os requisitos, veja scripts de terceiros na página de pagamento.

Onde o Proteside entra

O Proteside cobre a segunda e a quarta camada no navegador de quem compra: mantém o inventário de scripts da página de pagamento e confere, em cada pedido, se o QR, o Copia e Cola, a linha digitável e o formulário de cartão são os que a loja emitiu. Quando não são, bloqueia a troca antes da confirmação, avisa a loja e registra o caso como evidência para o PCI DSS. Veja como funciona.