TL;DR: deteção de skimmer na primeira sessão afetada
- O CSP é um porteiro: Uma Content Security Policy é um porteiro, não um guarda-costas. Impede o carregamento de novos scripts, mas deixa passar uma tag aprovada na qual um fornecedor introduziu um skimmer durante a noite.
- Linha de base de cada script de pagamento: A proteção Magecart mais sólida estabelece uma linha de base de comportamento para cada script da página de pagamento e alerta, na mesma sessão em que muda, quando um script permitido começa a tocar em campos de formulário que nunca antes tocou. É essa a deteção de adulteração em tempo de execução que o Requisito 11.6.1 do PCI DSS 4.0.1 exige, e que uma CSP não consegue fornecer.
- A checklist do comprador: Se uma ferramenta fecha realmente a lacuna resume-se a uma breve lista de verificação, abordada nos critérios de compra mais abaixo: monitorização em tempo real em sessões de utilizadores reais, deteção de alterações de comportamento em scripts já aprovados, arquivo de payloads desofuscados para análise forense e evidência validada por QSA para os Requisitos 6.4.3 e 11.6.1. Pontue cada opção da tabela comparativa em relação a ela.
Sem tempo? Veja o bloqueio in-browser de Magecart e skimmers da cside. Cobre tudo o que se segue numa única implementação.
O melhor software de proteção contra Magecart vigia em tempo real cada script da sua página de pagamento e emite um alerta no instante em que qualquer script, próprio ou de terceiros, lê um campo de pagamento ou envia dados para um endpoint que não devia. Uma Content Security Policy impede o carregamento de scripts desconhecidos, mas não consegue detetar uma alteração de comportamento dentro de um script que já aprovou, e é por isso que o PCI DSS 4.0.1 exige agora monitorização da integridade dos scripts em tempo de execução nas páginas de pagamento.
Os ataques Magecart comprometem a cadeia de fornecimento de JavaScript nas páginas de pagamento. Um atacante injeta código de skimming num script de terceiros que o seu site já carrega e no qual confia (uma tag de analítica, um widget de chat, um pixel de marketing), e esse script começa a recolher dados de cartões de pagamento dos campos do formulário de checkout sem qualquer alteração visível na página. Um checkout médio carrega dezenas de scripts de terceiros, e cada um é um potencial ponto de injeção.
O PCI Security Standards Council concretizou este risco no PCI DSS 4.0.1. O Requisito 6.4.3 obriga a que todos os scripts das páginas de pagamento sejam inventariados e autorizados. O Requisito 11.6.1 obriga à deteção de adulteração, ou seja, alertas automáticos quando qualquer script de uma página de pagamento altera o seu comportamento. Ambos os requisitos tornaram-se obrigatórios em 2025-03-31.
| Ferramenta | Monitorização de scripts em tempo real | Deteta alterações de comportamento em scripts aprovados | Arquivo de payload desofuscado / evidência forense | Evidência PCI DSS 6.4.3 + 11.6.1 | Nível gratuito |
|---|---|---|---|---|---|
| cside | Sim, 100% das sessões de utilizadores reais, sem amostragem | Sim, linha de base de comportamento por script | Sim, arquivo de payloads imutável | Sim, validado por QSA (VikingCloud) | Sim (1,000 chamadas de API/mês) |
| Reflectiz | Scanner remoto periódico, não sessões de utilizadores reais | Apenas no momento do scan | Não documentado nesta comparação | Relatórios autodescritos, podem exigir validação independente | Não documentado nesta comparação |
| Source Defense | Agente JS do lado do navegador mais crawler | Sim, comportamental (lado do navegador) | Não, não consegue mostrar o conteúdo dos scripts | Registos de deteção, não evidência de payload de grau forense | Não |
| Jscrambler | Scan periódico mais armadilhas no navegador | Baseado em armadilhas, pode não disparar | Não, não rastreia o conteúdo dos scripts | Registos comportamentais, sem evidência de payload | Não |
| DomDog | Agente de navegador mais relatórios CSP | Comportamental; a CSP não deteta alterações de conteúdo da mesma origem | Não, sem análise ou arquivo de payload | Concebido para 6.4.3 + 11.6.1, sem arquivo de payload | Não ($999/year de entrada) |
| Content Security Policy sozinha | Não, bloqueia novos scripts, não alterações de comportamento | Não | Não | Não | Gratuito (nativo do navegador) |
Porque é que uma Content Security Policy é necessária mas não suficiente
Uma Content Security Policy (CSP) é uma lista de permissões aplicada pelo navegador que bloqueia o carregamento de scripts a menos que a sua origem esteja explicitamente permitida. Para o Magecart, uma CSP impede que um atacante injete um novo script externo numa página de pagamento.
Não impede que um atacante comprometa um script que já está na lista de permissões. Se um atacante obtiver acesso ao CDN ou ao repositório de código de um fornecedor terceiro que a sua CSP já permite, pode modificar o script desse fornecedor para incluir código de skimming. A CSP vê o script a carregar a partir da mesma origem permitida e permite-o, por isso o skimmer é executado dentro de um script aprovado.
O Requisito 11.6.1 existe porque o PCI SSC reconheceu esta lacuna. Pede-lhe que detete quando um script aprovado altera o que faz, o que exige monitorização de comportamento em tempo de execução. Uma CSP não consegue fornecer isso.
cside: deteção de Magecart em tempo real
A proteção Magecart da cside monitoriza em tempo real cada script carregado na página de pagamento. Estabelece uma linha de base de comportamento para cada script aprovado (a que elementos do DOM acede, que destinos de rede chama, que dados lê) e alerta assim que qualquer script se desvia dessa linha de base.
Quando um script de terceiros comprometido começa a aceder a campos do formulário de pagamento que não tinha tocado antes, a cside deteta a alteração na mesma sessão em que ocorre. O alerta identifica o script específico, a alteração de comportamento específica e o carimbo de data/hora, para que tenha evidência utilizável numa avaliação PCI.
A cside mantém também o inventário de scripts exigido pelo Requisito 6.4.3: uma lista completa e continuamente atualizada de cada script presente na página de pagamento, com o estado de autorização de cada um. Como o inventário e a deteção de adulteração são entregues numa única implementação validada, uma só ferramenta satisfaz ambos os requisitos. A cside está validada pela VikingCloud para os Requisitos 6.4.3 e 11.6.1 do PCI DSS 4.0.1.
Para contextualizar, o skimming de páginas de pagamento continua a ser um motor principal da compromissão de dados de cartões baseada na web para os comerciantes. Detetar a injeção Magecart na primeira sessão afetada é o que impede que um único fornecedor comprometido se torne um incidente massivo de dados de cartões.
Reflectiz
A Reflectiz é uma plataforma de segurança de sites que monitoriza os scripts de terceiros em busca de alterações de comportamento e risco. O seu modelo de deteção assenta em scans remotos periódicos a partir de infraestrutura de crawler: um navegador que corre a partir do IP de um fornecedor de nuvem visita as suas páginas segundo um calendário e reporta o que vê.
Para o Magecart, esse modelo de scan agendado é a limitação central. Um navegador a partir de um IP de nuvem conhecido não equivale a um script a correr dentro do DOM real de uma sessão de utilizador real, e os skimmers do lado do cliente adaptam-se rotineiramente ao visitante. Um atacante que identifique o scanner pode servir-lhe uma página limpa enquanto os compradores reais recebem a versão maliciosa, pelo que um scanner pode criar uma falsa sensação de cobertura entre scans. Um scanner pontual como a Reflectiz vê ainda menos do que um agente em página amostrado, porque não corre em nenhuma sessão de utilizador real, apenas no que acontece carregar durante o seu rastreio agendado. Quanto às garantias, com base nos materiais públicos revistos em 2026-05-20, a Reflectiz não publicava uma aprovação QSA equivalente, PCI DSS SAQ D nem certificação SOC 2 Type II, e não publica qualquer página de estado pública ou SLA de disponibilidade; o seu preço também não é público.
A cside corre em 100% das sessões de utilizadores reais sem amostragem e descarrega cada script para a sua própria infraestrutura para análise do lado do servidor, de modo que um agente malicioso não lhe consegue servir um script limpo como consegue a um crawler agendado, e cada payload é arquivado como evidência. A cside também oferece cobertura baseada em scanner através do seu Scan Method para casos em que não é possível implementar um script, mas não faz do scan todo o modelo de segurança, e está validada por QSA pela VikingCloud para os Requisitos 6.4.3 e 11.6.1 do PCI DSS 4.0.1.
Source Defense
A Source Defense especializa-se em segurança de sites do lado do cliente e dirige-se a comerciantes empresariais. Oferece dois métodos para os scripts das páginas de pagamento: Source Defense Detect, um crawler que imita um utilizador a visitar a página para obter os scripts de terceiros que carregam, e Source Defense Protect, um agente JavaScript que constrói um sandbox do lado do cliente para isolar os scripts e limitar aquilo a que podem aceder.
Para o Magecart, ambos os métodos têm falhas que um skimmer pode explorar. O crawler é apenas uma combinação específica de localização, dispositivo e momento, por isso não captura o payload exato que um visitante real recebe, e um atacante pode detetar a infraestrutura de nuvem e servir-lhe um script limpo. O agente JavaScript é baseado em gatilhos, por isso tudo o que não acione um gatilho é tratado como bom, e como os gatilhos são definidos no navegador, um agente malicioso pode estudá-los e conceber um skimmer que os evita. O sandbox acrescenta até 100ms de latência, e como o agente corre no mesmo ambiente de navegador que o atacante, um script que já esteja a correr pode sobrepor-se a funções centrais como fetch e cortar o alerta antes de este sair da página. O mais importante para a análise forense de skimming: a Source Defense não consegue mostrar-lhe o conteúdo dos scripts, por isso provar o que um script comprometido realmente fez é difícil.
A cside analisa cada script do lado do servidor, em infraestrutura que o atacante não consegue ver nem com a qual pode interagir, de modo que a deteção não pode ser identificada e desativada como pode acontecer com um agente do lado do navegador. Quando uma deteção dispara, a cside preserva o payload malicioso exato num arquivo imutável, dando à sua equipa de resposta a incidentes e a um QSA o código de ataque real em vez de um alerta comportamental. O motor da cside também aprende o que cada script é suposto fazer e assinala os desvios automaticamente, em vez de exigir as regras de permissão por script que um modelo de sandbox precisa de manter atualizadas à medida que o seu checkout evolui.
Jscrambler
A Jscrambler começou na ofuscação de JavaScript e mais tarde acrescentou um produto de integridade de páginas web. A sua força principal é proteger o JavaScript próprio, transformando o código proprietário para que seja mais difícil de fazer engenharia inversa, com "bloqueios de código" que restringem onde e quando o código corre. Para a deteção de ameaças do lado do cliente, usa uma abordagem baseada em armadilhas: injeta objetos-engodo e código de monitorização nas suas páginas e espera que um script malicioso interaja com essas armadilhas.
Para o Magecart, a deteção baseada em armadilhas tem a mesma fraqueza central que qualquer modelo apenas de navegador: não sabe o que não apanhou. Um skimmer que evita os objetos-engodo ou bloqueia os endpoints de callback passa despercebido, e como o código de monitorização corre no navegador, um atacante sofisticado consegue encontrá-lo e contorná-lo. A Jscrambler não rastreia de todo o conteúdo dos scripts, por isso após um ataque amostrado ou condicional muitas vezes não resta qualquer payload malicioso para analisar, o que dificulta a análise forense e a evidência PCI. A ofuscação também não fecha a lacuna, já que o navegador continua a executar chamadas de API observáveis e a desofuscação assistida por LLM lê cada vez melhor a intenção.
A cside foi construída para a segurança do lado do cliente e para o PCI DSS 6.4.3 e 11.6.1 desde o início. Monitoriza o comportamento dos scripts em sessões de utilizadores reais sem amostragem, descarrega cada script para uma análise profunda na sua própria infraestrutura (usando LLMs que executa ela própria, por isso nenhum dado de script sai para um fornecedor de IA terceiro) e arquiva o código de ataque em bruto para revisão por QSA. Na categoria independente de Segurança do Lado do Cliente dos Globee Cybersecurity Awards 2026, a cside conquistou o Ouro (Melhor da Categoria) e a Jscrambler conquistou a Prata.
DomDog
A DomDog foi concebida especificamente para os requisitos 6.4.3 e 11.6.1 do PCI DSS 4.0.1, com informação de produto totalmente pública e um preço que começa nos $999 por ano, semelhante à cside. A configuração é um único script adicionado à tag do header. Funciona como um agente JavaScript que recolhe dados, mostra os scripts num painel e pede ao utilizador que os reveja e os coloque numa lista de permissões ou de bloqueio, apoiado por uma Content Security Policy secundária.
Para o Magecart em concreto, esse design de agente mais CSP deixa uma janela de skimming real. Como a DomDog não se situa no fluxo de entrega dos scripts, um script XSS armazenado que se torna malicioso pode ativar-se sem ser apanhado, e a sua CSP confia em origens pré-aprovadas em vez do seu conteúdo, por isso uma troca de conteúdo da mesma origem, exatamente o padrão Polyfill em que polyfill[.]io continuava a ser o domínio mas o payload mudava, passa despercebida. A DomDog monitoriza as alterações de comportamento mas não analisa nem arquiva payloads, por isso a deteção acontece após a entrega e não há código de ataque para entregar a um auditor. A cside não conseguiu encontrar qualquer certificação SOC 2 ou PCI DSS publicada para a DomDog.
A cside realiza a análise de payloads na sua própria infraestrutura, descarregando os scripts do lado do servidor e identificando a intenção maliciosa ao nível do código, o que apanha skimmers direcionados que só se ativam sob condições específicas como certas geografias, janelas de tempo ou tipos de dispositivo. Mantém arquivos imutáveis de cada payload de script com o histórico de versões completo, por isso uma auditoria obtém o código de ataque real e uma cronologia completa em vez de um registo de alterações de comportamento, e a sua cobertura estende-se para além das normas de cartões de pagamento a HIPAA, GDPR e CPRA.
Como escolher software de proteção contra Magecart
Ignore os nomes dos fornecedores e pontue cada opção da tabela comparativa em relação a estes critérios. O Magecart é uma ameaça em tempo de execução e dentro da sessão, por isso uma ferramenta tem de os cumprir a todos, não a maioria, para fechar realmente a lacuna:
- Monitorização de scripts em tempo real em 100% das sessões de utilizadores reais, sem amostragem. Um scanner remoto periódico ou um crawler a partir de infraestrutura de nuvem pode receber um script limpo enquanto os compradores reais são alvo de skimming. A cobertura tem de se situar no tráfego real de utilizadores, não numa visita agendada.
- Deteta alterações de comportamento em scripts já aprovados. O vetor Magecart mais comum é um script comprometido que já estava na sua lista de permissões. Bloquear novos scripts não basta; a ferramenta deve assinalar quando um script permitido começa a ler campos de formulário ou a chamar endpoints que nunca antes tocou.
- Deteção que o atacante não consegue ver nem desativar. Se a monitorização corre inteiramente no navegador, um agente malicioso pode estudar os gatilhos e contorná-los, ou intercetar o alerta antes de este sair da página. A análise na própria infraestrutura do fornecedor remove essa superfície de ataque.
- Arquivo de payloads desofuscados para análise forense. Os alertas comportamentais por si só não provam o que aconteceu. Quer um arquivo imutável do código de ataque real (desofuscado), porque os skimmers são muitas vezes amostrados ou condicionais e de outra forma não deixam nada para trás.
- Evidência validada por QSA para o PCI DSS 6.4.3 e 11.6.1. Ambos os requisitos tornaram-se obrigatórios em 2025-03-31. Os relatórios autodescritos podem ainda exigir validação independente no momento da avaliação, por isso exija validação QSA independente, não uma caixa assinalada.
- Um nível gratuito para o provar antes de assinar. Deve conseguir verificar a deteção nas suas próprias páginas de pagamento antes de comprometer orçamento.
Pontue cada ferramenta com honestidade em relação a esta lista. Apenas uma linha da tabela acima cumpre todos os critérios.
Content Security Policy sozinha
Uma CSP é um controlo gratuito e nativo do navegador, e deve ser implementada em cada página de pagamento como base. Não substitui o software de monitorização em tempo de execução.
Uma CSP bem configurada com nonces ou hashes nos scripts inline previne a maioria das injeções Magecart oportunistas. Não monitoriza o comportamento em tempo de execução dos scripts aprovados, não alerta quando um script aprovado altera o que faz, e não produz o registo de auditoria exigido pelo Requisito 11.6.1 do PCI DSS 4.0.1. Trate uma CSP como o ponto de partida, não como a solução completa.
Experimente o cside antes de comprar. O cside tem um plano gratuito, então você pode se cadastrar, implantar e explorar a plataforma por conta própria, sem ligações de vendas ou processo de compra. E nossa equipe de suporte está a uma mensagem de distância sempre que precisar de ajuda.
