O Magecart é uma classe de ataque client-side em que JavaScript malicioso corre dentro do navegador de um utilizador, capturando silenciosamente os dados dos cartões de pagamento à medida que são introduzidos e transmitindo-os para um servidor controlado pelo atacante. O ataque acontece inteiramente dentro do ambiente do navegador, depois de a página ter carregado e antes de a transação chegar ao processador de pagamentos. As ferramentas de segurança server-side, os WAFs e a inspeção de rede não o conseguem observar, porque os dados nunca saem do navegador numa forma que estas consigam intercetar.
O termo teve origem num grupo de ameaças específico documentado a partir de 2016. Hoje descreve a classe de ataque mais ampla: qualquer ataque de skimming que opera na camada do navegador, seja através de injeção direta de scripts, comprometimento da supply-chain de um fornecedor confiável ou modificação do payload de um tag manager. O mecanismo é o mesmo, independentemente do ponto de entrada: código malicioso lê os valores dos campos de formulário e exfiltra-os antes do envio.
O Cost of a Data Breach Report 2024 da IBM situa o custo médio global de uma violação em 4,88 milhões de USD. O Data Breach Investigations Report 2024 da Verizon lista os ataques a aplicações web entre os três padrões de violação confirmada mais comuns no setor do retalho. Os requisitos 6.4.3 e 11.6.1 do PCI DSS 4.0.1, obrigatórios desde 31 de março de 2025, foram escritos especificamente para responder à classe de ataque Magecart através do inventário de scripts, da governação de autorizações e da deteção de alterações em runtime.
O desafio para as equipas de segurança não é a consciencialização. É selecionar uma plataforma com a arquitetura de deteção capaz de apanhar um ataque Magecart real. Esta análise avalia cinco plataformas de client-side security face aos requisitos de deteção de um modelo de ameaça Magecart prático.
O que é o Magecart? O Magecart é uma técnica de ataque client-side em que JavaScript malicioso é injetado no ambiente de execução do navegador de um site para capturar os dados dos cartões de pagamento a partir dos campos de formulário antes de estes chegarem ao processador de pagamentos. O código corre dentro do navegador, invisível para a monitorização server-side, os WAFs e as ferramentas de inspeção de rede. Os ataques Magecart modernos são entregues através do comprometimento da supply-chain de scripts de fornecedores confiáveis, e não apenas por injeção direta.
O que a Deteção de Magecart Exige Realmente
Resposta rápida: Três capacidades separam a deteção genuína de Magecart da monitorização de scripts de nível meramente regulamentar: cobertura de sessões de utilizadores reais ao longo de toda a jornada de compra (não apenas o checkout), deteção de desvios comportamentais ao nível do script e arquivo de evidência ao nível de resposta a incidentes (IR) que regista o que estava a correr no navegador no momento do ataque. Uma plataforma à qual falte qualquer uma destas não detetará categorias inteiras de ataque ativo.
Cobertura de toda a jornada de compra. A ação de aplicação da lei do Information Commissioner's Office contra a British Airways concluiu que cerca de 500.000 clientes foram afetados ao longo de um período de 15 dias em 2018 por um ataque de script na camada do navegador. Os payloads modernos de Magecart ativam-se nas páginas de produto e de carrinho, e não apenas no passo de checkout, porque os sinais de intenção de compra e as interações preliminares com formulários começam mais cedo na sessão. Uma plataforma que cobre apenas a página de pagamento deixa escapar uma parte significativa da superfície de ataque atual.
Monitorização de sessões de utilizadores reais. Os payloads de Magecart são cada vez mais construídos para escapar à análise periódica e sintética. As técnicas de evasão comuns incluem a ativação por tempo limitado (o payload só corre durante horas específicas), o geo-targeting (o código só se ativa para utilizadores em determinados países) e a deteção por session-fingerprint (o payload suprime-se a si próprio quando deteta comportamento típico de bot). Uma plataforma que analisa segundo um calendário, a partir de um crawler ou usando sessões sintéticas é especificamente contornada por estas técnicas. A monitorização de sessões de utilizadores reais não tem qualquer lacuna de deteção, porque o ataque corre na primeira sessão real em que a versão comprometida está ativa.
Deteção de desvios comportamentais. Os ataques Magecart de supply-chain chegam através de scripts de fornecedores confiáveis. Um script de fornecedor servido por CDN e comprometido pode trazer um hash novo, de aparência legítima, a partir de uma origem autorizada. A monitorização baseada apenas em hash não assinala este ataque, porque tanto a origem como o canal de entrega são permitidos. A deteção de desvios comportamentais estabelece uma baseline do que cada script faz em runtime (leituras de elementos do DOM, acesso a campos de formulário, destinos de rede de saída, importações dinâmicas) e assinala alterações de comportamento, independentemente de o hash ou a origem parecerem normais.
Arquivo de evidência ao nível de IR. A análise forense das redes de cartões e os reguladores de proteção de dados exigem documentação do que estava a correr no navegador durante um comprometimento confirmado, que sessões foram afetadas e que dados estavam em causa. As plataformas que arquivam payloads de scripts desofuscados com carimbos temporais por sessão conseguem reconstruir um incidente específico a partir do registo de evidência. As plataformas que retêm apenas metadados de alertas e notificações de alterações não conseguem responder a essas perguntas.
As Plataformas
cside
Melhor para: equipas de segurança de eCommerce que precisam de deteção de Magecart em toda a sessão ao longo da jornada de compra completa, com evidência de conformidade PCI DSS validada por QSA e arquivo de payloads ao nível de IR, numa única plataforma.
A cside monitoriza cada sessão de utilizador real desde o carregamento da página até à conclusão da transação, cobrindo páginas de produto, páginas de carrinho e checkout. A plataforma deteta alterações de scripts em cinco categorias: URL, hash, comportamental, caminho de execução e destino. A deteção de desvios comportamentais estabelece uma baseline de runtime para cada third-party script e assinala alterações no que o script faz, e não apenas alterações no que ele é, pelo que os ataques Magecart de supply-chain são apanhados independentemente do estado do hash ou da origem.
As alterações de scripts são detetadas em menos de 60 segundos em média ao longo das sessões de utilizadores reais (dados de produto da cside). O modelo de arquivo de payloads desofuscados regista a versão legível de qualquer alteração de script ofuscado juntamente com o carimbo temporal por sessão e os destinos de rede, respondendo às perguntas forenses que as redes de cartões e os reguladores fazem após um incidente confirmado. No 1.º trimestre de 2025, a cside detetou mais de 300.000 sinais de ataque client-side nunca antes vistos ao longo das implementações dos clientes.
Nos 2026 Globee® Cybersecurity Awards, um júri independente atribuiu à cside o Gold Globee® Award (Best of Category) em Client-Side Security; a Jscrambler recebeu o Silver. Veja a comparação completa cside vs Jscrambler.
O painel PCI Shield cobre tanto o requisito 6.4.3 como o 11.6.1, com evidência validada pelo QSA da VikingCloud. O onboarding self-service e o pricing transparente permitem que as equipas de segurança atinjam uma postura de client-side security funcional sem um compromisso de serviços.
Source Defense
Melhor para: comerciantes que querem limitar o raio de impacto de um comprometimento Magecart de supply-chain a um nível estrutural, através de sandboxing, em vez de depender da deteção depois do facto.
A Source Defense coloca os third-party scripts numa sandbox, num ambiente de execução isolado que restringe o seu acesso aos elementos do DOM e aos campos de formulário da página de pagamento. Um script de fornecedor comprometido pela supply-chain que corra na sandbox não consegue ler os dados do cartão, mesmo que o comprometimento não seja detetado de imediato, porque as restrições estruturais impedem o caminho de acesso de que um skimmer precisa.
Para os comerciantes em que a latência de deteção é uma preocupação primária (um skimmer a correr durante horas no decurso de um ciclo de análise é inaceitável), o sandboxing como controlo primário elimina essa janela. A Source Defense também satisfaz os requisitos 6.4.3 e 11.6.1 do PCI DSS para o inventário de scripts e a monitorização de alterações. Avalie a compatibilidade com o JavaScript do processador de pagamentos antes de implementar a camada de sandboxing.
Reflectiz
Melhor para: plataformas de fintech e eCommerce que acarretam risco de PCI DSS a par de obrigações de RGPD ou HIPAA, e que precisam de mapear o comportamento dos scripts a múltiplos enquadramentos de conformidade em simultâneo.
A Reflectiz monitoriza o comportamento dos third-party scripts e mapeia-o às obrigações regulamentares. A funcionalidade Policies, lançada em abril de 2026, permite regras de aplicação automatizadas: os scripts que violam perfis comportamentais definidos despoletam respostas automáticas, reduzindo a carga de revisão manual em ambientes com cadências de atualização de fornecedores de elevada velocidade.
Para organizações de fintech em que um comprometimento ao estilo Magecart de um third-party script cria tanto uma obrigação de evidência de PCI DSS como um requisito de notificação ao abrigo do RGPD, a cobertura unificada de enquadramentos reduz a sobrecarga operacional de manter pacotes de evidência separados. A Reflectiz usa uma abordagem de monitorização por navegador remoto; valide a cobertura de sessões de utilizadores reais face ao seu modelo de ameaça de evasão antes de a selecionar como o controlo primário de deteção de Magecart.
Jscrambler
Melhor para: equipas de desenvolvimento de eCommerce que detêm uma quantidade significativa de JavaScript próprio (first-party) no fluxo de checkout e que precisam de monitorização de Magecart em third-party scripts a par da proteção do seu código first-party.
A funcionalidade Webpage Integrity da Jscrambler cobre a monitorização de third-party scripts para os requisitos 6.4.3 e 11.6.1 do PCI DSS, a par de ofuscação, código de autodefesa e deteção de adulteração para o JavaScript first-party. Para comerciantes com código proprietário substancial no caminho de checkout, o modelo integrado responde tanto ao risco de proteção do código interno como ao requisito de conformidade relativo a terceiros.
A profundidade da deteção comportamental para ataques Magecart de supply-chain deve ser validada diretamente face ao seu modelo de ameaça específico, em particular para ataques que usam importações dinâmicas ou evasão comportamental, antes de selecionar a Jscrambler como o controlo primário de deteção em runtime.
HUMAN Security: Page Protect
Melhor para: grandes plataformas de eCommerce que acarretam tanto risco de Magecart como fraude de pagamentos impulsionada por bots, e que querem cobertura unificada da camada do navegador num único contrato de fornecedor.
O Page Protect da HUMAN responde ao risco de scripts client-side como parte da sua plataforma mais ampla de gestão de bots e prevenção de fraude. Para operações de eCommerce em que o credential stuffing, o abuso de inventário e a fraude de pagamentos coexistem com o risco de skimmer, um único fornecedor a cobrir ambas as superfícies reduz a complexidade de gerir múltiplas ferramentas especializadas.
A HUMAN é primariamente uma plataforma de prevenção de bots e fraude; a capacidade de monitorização de scripts client-side é robusta, mas pode ser menos granular na produção de evidência de PCI DSS e no arquivo de payloads ao nível de IR do que os especialistas dedicados. As equipas de segurança com um modelo de ameaça específico de Magecart devem validar as capacidades de deteção comportamental do Page Protect face à cside e à Jscrambler antes de se comprometerem.
Comparação Num Relance
| Plataforma | Jornada de compra completa | Sessões de utilizadores reais | Desvio comportamental | Arquivo desofuscado | PCI 6.4.3 + 11.6.1 |
|---|---|---|---|---|---|
| cside | Sim | Sim (100%) | Sim | Sim | Sim (validado por QSA) |
| Source Defense | Sim | Sim | Via sandboxing | Parcial | Sim |
| Reflectiz | Parcial | Navegador remoto | Apenas sintético | Parcial | Sim |
| Jscrambler | Sim | Sim | Parcial | Limitado | Sim |
| HUMAN Page Protect | Sim | Sim | Parcial | Limitado | Parcial |
Como Escolher
Resposta rápida: Se o seu risco primário é o skimming Magecart ativo e precisa de evidência ao nível de IR para reconstruir um incidente confirmado, dê prioridade às plataformas com monitorização de 100% das sessões de utilizadores reais, deteção de desvios comportamentais e arquivo de payloads desofuscados. Se o objetivo é a prevenção e não a deteção, uma abordagem de sandboxing limita estruturalmente o que um script comprometido consegue alcançar antes de a deteção ocorrer.
Se precisa de detetar Magecart ativo e produzir evidência forense: a cside oferece a cobertura mais completa, jornada de compra completa, monitorização de 100% das sessões, deteção de desvios comportamentais, arquivo desofuscado e evidência de conformidade PCI DSS validada por QSA.
Se a prevenção estrutural é o controlo primário: a abordagem de sandboxing da Source Defense limita o raio de impacto de um comprometimento de supply-chain antes de a deteção ocorrer. Avalie a compatibilidade da sandbox com o JavaScript do seu processador de pagamentos antes da implementação.
Se acarreta múltiplos enquadramentos de conformidade a par do PCI DSS: a Reflectiz mapeia o comportamento dos scripts entre PCI, RGPD e HIPAA em simultâneo. Valide a cobertura por navegador remoto face ao seu modelo de ameaça de evasão de Magecart.
Se a proteção do JavaScript first-party também está em causa: a Jscrambler cobre a monitorização de terceiros e a ofuscação first-party numa única plataforma. Valide a profundidade da deteção comportamental de terceiros face aos atuais padrões de ataque Magecart.
Para uma visão mais ampla de como estes controlos se encaixam nas stacks de eCommerce e fintech, consulte o nosso guia sobre client-side security para plataformas de eCommerce e fintech e como avaliar ferramentas de visibilidade em tempo real de ataques no navegador.
