TL;DR: conformidade PCI no Magento
- O Magento não cuida dos requisitos 6.4.3 e 11.6.1 por você. Cada script da sua página de pagamento precisa de uma entrada no inventário, uma justificativa de negócio e monitoramento contínuo de integridade.
- Os scans ASV atendem ao requisito 11.3.2. Eles não detectam ameaças de JavaScript nas páginas de pagamento. Lojistas que tratam o scan ASV como sua principal verificação de segurança deixam de fora justamente os controles que o PCI DSS 4.0.1 exige para o risco no lado do cliente.
- O vetor de ataque mais comum contra o Magento em 2024 e 2025 é a exfiltração via WebSocket a partir de extensões comprometidas. Ela contorna a CSP, contorna o monitoramento de rede e só fica visível para uma ferramenta que observa o runtime do navegador diretamente.
O que é conformidade PCI no Magento?
Lojas Magento não são automaticamente conformes com o PCI DSS. O Magento Commerce Cloud cuida de parte dos controles no nível da infraestrutura, mas o lojista continua responsável por proteger as páginas de pagamento contra ataques no lado do cliente. Os requisitos 6.4.3 e 11.6.1 do PCI DSS 4.0.1 exigem que todos os scripts das páginas de pagamento sejam inventariados, autorizados e monitorados quanto a mudanças de integridade. São controles que o Magento não oferece de forma nativa, qualquer que seja a extensão de pagamento usada.
O equívoco mais comum: lojistas presumem que usar uma extensão de pagamento certificada, ou delegar o processamento a uma página de pagamento hospedada, já cumpre o PCI DSS. Isso reduz o escopo, mas não o elimina. Qualquer página Magento que carregue funcionalidade de checkout, ou que entre no ambiente de dados do portador do cartão por carregar scripts de terceiros, está no escopo dos requisitos 6.4.3 e 11.6.1.
Uma página de checkout típica do Magento carrega pixels de rastreamento, tags de analytics, ferramentas de teste A/B, scripts de afiliados, widgets de chat e bibliotecas de pagamento. Cada um está no escopo. Cada um exige uma entrada de inventário com justificativa de negócio. Cada um precisa ser monitorado quanto a mudanças de integridade entre avaliações.
Requisitos do PCI DSS que lojistas Magento costumam descumprir
Requisito 6.4.3: inventário e autorização de scripts. Todo script carregado em uma página de pagamento precisa estar inventariado. O inventário deve documentar a justificativa de negócio de cada script, confirmar que ele está autorizado e incluir um método para verificar que sua integridade não foi alterada. Uma lista estática em uma planilha não cumpre esse requisito: o inventário precisa refletir o estado real da página de pagamento, porque os scripts mudam.
Requisito 11.6.1: detecção de adulteração na página de pagamento. O lojista precisa ter um mecanismo que detecte alterações não autorizadas nos cabeçalhos HTTP e no conteúdo da página de pagamento, e que avise a equipe responsável dentro de um prazo definido. Uma revisão manual periódica não cumpre esse requisito. O mecanismo precisa ser capaz de detectar o surgimento de um script novo, a alteração de um script existente ou a modificação de um cabeçalho HTTP entre ciclos de revisão.
Os dois requisitos passaram a ser obrigatórios em 2025-03-31 e já são avaliados ativamente. Se a sua loja Magento não tem uma ferramenta que produza evidência contínua para eles, a sua próxima avaliação PCI DSS está em risco.
O que é um Approved Scanning Vendor (ASV)?
Um Approved Scanning Vendor (ASV) é uma empresa certificada pelo PCI SSC para realizar scans externos de vulnerabilidades, conforme exige o requisito 11.3.2 do PCI DSS. Os scans ASV sondam os componentes de rede expostos à internet em busca de vulnerabilidades conhecidas. Eles não detectam ameaças de JavaScript no lado do cliente nas páginas de pagamento, nem scripts de terceiros não autorizados, nem as anomalias de comportamento tratadas pelos requisitos 6.4.3 e 11.6.1. Passar em um scan ASV não significa que o seu checkout Magento esteja protegido contra ataques do tipo Magecart.
O que os scans ASV fazem: sondar seus endereços IP e domínios públicos em busca de CVEs conhecidos, portas abertas, serviços mal configurados e vulnerabilidades no nível de rede. Um relatório ASV limpo confirma que o perímetro dos seus servidores não tem vulnerabilidades exploráveis conhecidas e detectáveis de fora.
O que os scans ASV não fazem: analisar o JavaScript executado nas suas páginas de pagamento, detectar scripts que não existiam no scan anterior, verificar se scripts de terceiros foram modificados desde a última aprovação, ou observar quais dados os scripts enviam a endpoints externos durante uma sessão real de visitante.
Essa lacuna não é uma crítica ao scan ASV. É a descrição daquilo para que a ferramenta foi feita. Os controles de conformidade que tratam de ameaças de JavaScript no lado do cliente são o 6.4.3 e o 11.6.1, não o 11.3.2. Uma loja Magento pode passar em todos os scans ASV trimestrais enquanto executa um script comprometido que exfiltra dados de portadores de cartão em tempo real.
O vetor de ataque no Magento que os scans ASV não conseguem ver
A cside acompanha as TTPs ativas contra lojistas Magento. O padrão de ataque mais sofisticado observado em 2024 e 2025 usa conexões WebSocket para exfiltração, em vez de requisições HTTP convencionais.
Por que WebSockets escapam das defesas tradicionais:
Ataques Magecart clássicos exfiltram dados por requisições HTTP POST para domínios controlados pelo atacante. Diretivas connect-src da CSP podem bloqueá-las se o domínio do atacante não estiver na lista de permissões. Ferramentas de monitoramento de rede enxergam o POST de saída e podem sinalizá-lo.
Conexões WebSocket com o protocolo wss:// são diferentes. Muitas configurações de CSP não restringem as origens WebSocket separadamente das origens HTTP. Ferramentas de monitoramento voltadas ao tráfego HTTP podem não ver as conexões wss:// de jeito nenhum. O atacante mantém um canal bidirecional persistente com o navegador da vítima, consegue alterar os scripts injetados durante a sessão sem provocar um novo carregamento de página e consegue exfiltrar dados de cartão de forma contínua, em vez de em requisições POST isoladas.
O vetor de acesso: o CosmicSting (CVE-2024-34102), divulgado em junho de 2024, permitia que atacantes não autenticados lessem arquivos do servidor em instalações do Adobe Commerce e do Magento, incluindo arquivos de configuração com credenciais de banco de dados e chaves de API. De posse dessas credenciais, os atacantes injetaram o skimmer baseado em WebSocket diretamente nas páginas de checkout do Magento. O patch do CVE-2024-34102 fecha o vetor de acesso inicial. Ele não remove scripts já injetados. Lojistas que aplicaram o patch mas não auditaram os scripts das suas páginas de pagamento em busca de artefatos pós-exploração podem continuar servindo o skimmer.
A única camada de detecção que pega esse ataque é a que instrumenta o runtime do navegador diretamente: observar quais scripts são executados em sessões reais de visitantes, quais chamadas de API eles fazem e para onde enviam dados, em tempo real, em cada sessão.
Como a cside protege checkouts Magento
A cside é implantada como um único snippet JavaScript de primeira parte nas suas páginas de checkout do Magento. Ela monitora o runtime do navegador em cada sessão real de visitante e produz evidência contínua para os requisitos 6.4.3 e 11.6.1.
Para o requisito 6.4.3: a cside mantém um inventário vivo de todo script que carrega em cada página monitorada, incluindo o campo de justificativa de negócio, o status de autorização e o hash de integridade a cada carregamento. Quando um script novo aparece, ou um script existente muda, o inventário é atualizado e um alerta é disparado.
Para o requisito 11.6.1: a cside detecta alterações nos scripts e nos cabeçalhos HTTP das páginas de pagamento em tempo real, em sessões reais de visitantes, e gera uma trilha de evidências com registro de data e hora que os QSAs aceitam para o requisito.
Para ataques via WebSocket: como a cside instrumenta o runtime de JavaScript diretamente, ela observa as conexões WebSocket abertas pelos scripts da página, estejam elas visíveis ou não nos logs de tráfego HTTP e cobertas ou não pela CSP.
Veja como cumprir o PCI 6.4.3 e 11.6.1 para o passo a passo detalhado de implementação.
