Roubo de dados de cartão no checkout: como a cópia acontece

O roubo de dados de cartão no checkout funciona assim: um pedaço de código malicioso, escondido na página de pagamento de uma loja legítima, lê o que o cliente digita (número, validade, código de segurança) e envia uma cópia para o criminoso enquanto a compra segue normalmente. A loja recebe o pagamento, o cliente recebe o pedido e ninguém percebe nada até que compras estranhas apareçam na fatura.

O que acontece na tela do cliente

Toda página de pagamento é montada no navegador do comprador a partir de várias peças de código: as da própria loja, as da plataforma de e-commerce, as de plugins e as de parceiros, como ferramentas de análise de tráfego, chat ou avaliações. Todas rodam juntas, dentro da mesma página. Isso é útil (é o que permite, por exemplo, avisar na hora que o número do cartão está incompleto), mas também significa que qualquer código presente ali consegue enxergar o que é digitado nos campos.

O ataque explora exatamente isso. O criminoso insere o próprio código na página, seja invadindo o painel da loja, explorando uma falha da plataforma ou de um plugin, seja comprometendo um parceiro que fornece algum script. A partir daí, o roteiro é quase sempre o mesmo:

1. O cliente preenche o formulário de cartão, como em qualquer compra.
2. O código malicioso lê os campos enquanto ele digita ou no momento em que clica em pagar.
3. Uma cópia dos dados é enviada para um endereço controlado pelo criminoso, muitas vezes com nome parecido com o de um serviço legítimo de estatísticas.
4. A compra continua e é aprovada. Para a loja e para o cliente, nada saiu do normal.

O guia publicado pelo PCI Security Standards Council em março de 2025 chama esse tipo de ataque de silencioso: tudo funciona como esperado do ponto de vista do cliente e da loja e, por isso, ele pode passar muito tempo sem ser descoberto.

Casos reais que mostram o padrão

O caso mais bem documentado é o da British Airways. Segundo a decisão da autoridade britânica de proteção de dados (ICO), publicada em outubro de 2020, um invasor entrou na rede da companhia com credenciais de acesso remoto comprometidas e alterou um arquivo de código do site. Durante 15 dias, entre agosto e setembro de 2018, cada cliente que digitava os dados do cartão enviava, sem saber, uma cópia para um domínio parecido com o da empresa, e a reserva seguia sem nenhuma interrupção. Cerca de 430 mil pessoas podem ter sido afetadas, e quem avisou a companhia foi um terceiro, não um alarme interno. A ICO aplicou uma multa à empresa.

Em 2019, a equipe de prevenção a fraudes da Visa descreveu um código desse tipo, batizado de Pipka. Ele podia ser configurado para escolher quais campos copiar (número, validade, código de segurança, nome e endereço) e se apagava da página logo depois de rodar, para dificultar a investigação. A Visa o encontrou em pelo menos 17 lojas.

O problema não é pontual. Em dezembro de 2023, uma ação coordenada pela Europol com polícias de 17 países notificou 443 lojas virtuais de que dados de cartão de seus clientes tinham sido expostos, em apenas dois meses de trabalho. Em abril de 2026, a empresa de pesquisa Sansec relatou quase 100 lojas com um código escondido dentro de um elemento de imagem invisível, que enviava os dados para endereços disfarçados de estatísticas de uma rede social.

Por que as defesas tradicionais não enxergam

Firewall, antivírus no servidor e antifraude são importantes, mas olham para outro lugar. O antifraude avalia se a transação parece legítima, e ela é: o cliente é real, o cartão é dele e a compra também. O firewall protege a entrada do servidor. A cópia dos dados, porém, acontece no navegador do comprador, depois que a página já saiu do servidor.

Há ainda dois agravantes. O código malicioso costuma imitar ferramentas conhecidas, então passa despercebido numa revisão rápida. E revisar o código guardado no servidor da loja não mostra o que foi acrescentado depois, por um parceiro, por um gerenciador de tags ou diretamente na página publicada. Por isso a descoberta quase sempre vem de fora: um banco que percebe fraudes concentradas, a bandeira do cartão, um pesquisador.

O que fazer na sua loja

• Saiba o que roda no checkout. Liste todos os scripts carregados nas páginas de pagamento, quem é o responsável por cada um e por que ele precisa estar ali.
• Corte o excesso. Ferramentas de marketing, chat e avaliações raramente precisam estar na página onde o cartão é digitado.
• Feche as portas de entrada. Mantenha plataforma, tema e plugins atualizados, remova o que não usa e exija verificação em duas etapas em todo acesso administrativo e remoto.
• Restrinja destinos. Configure a página para só carregar código e só enviar dados para endereços autorizados.
• Vigie a página que o cliente recebe, não só o código no servidor: scripts novos ou alterados e envios para destinos desconhecidos devem gerar alerta imediato.
• Tenha um plano. Defina quem acionar (adquirente, provedor de pagamento, equipe técnica) se algo suspeito aparecer e como avisar os clientes.

Esses cuidados são também o centro dos requisitos 6.4.3 e 11.6.1 do PCI DSS, que passaram a ser obrigatórios em 31 de março de 2025.

O Proteside foi criado para esse momento: um script na página de pagamento que confere, no navegador do comprador, quem está lendo os campos do cartão e para onde os dados estão indo, e bloqueia a cópia antes que ela saia. Veja como funciona a proteção contra roubo de dados de cartão e teste grátis por 14 dias.