Como escolher uma ferramenta para o PCI DSS 6.4.3 e 11.6.1

Em 10 de março de 2025, o PCI Security Standards Council publicou um guia dedicado aos requisitos 6.4.3 e 11.6.1 do PCI DSS, três semanas antes de os dois se tornarem obrigatórios. De lá para cá, o mercado se encheu de ferramentas que prometem resolver os dois requisitos, e quem precisa escolher uma recebe propostas que não se comparam entre si: uma monitora scripts, outra visita a página de fora, outra promete resolver tudo na CDN. Este guia organiza essas opções e lista as perguntas que separam uma compra boa de uma compra que só serve até a próxima avaliação.

Resposta direta

Escolha pela cobertura dos dois requisitos ao mesmo tempo: inventário e autorização de scripts (6.4.3) e detecção de alterações com alerta (11.6.1). Prefira ferramentas que observam sessões reais de compradores, que cobrem todos os meios de pagamento da sua página (cartão de crédito, cartão de débito, Pix, boleto, carteiras) e que geram relatório pronto para o QSA sem exigir troca de infraestrutura.

Por que o requisito existe

O ataque que motivou os dois requisitos acontece no navegador do comprador. Um script é inserido na página de pagamento, seja por um plugin comprometido, por um fornecedor de terceiros invadido ou por uma alteração direta no servidor. Esse script copia os dados do cartão no momento da digitação e envia para o criminoso. A página continua funcionando, o pedido é aprovado e ninguém percebe por semanas.

O 6.4.3 ataca a causa: a empresa precisa saber quais scripts carregam na página de pagamento, quem autorizou cada um e por quê. O 11.6.1 ataca o efeito: a empresa precisa de um mecanismo que detecte alterações não autorizadas no conteúdo da página e nos cabeçalhos de segurança, e que avise quando isso acontecer.

Os requisitos falam de cartão, mas a mesma técnica troca o QR Code do Pix, a linha digitável do boleto e o endereço de uma carteira de stablecoin. Uma ferramenta que só olha para o campo do cartão deixa metade do checkout sem vigilância.

As quatro abordagens do mercado

1. Agente de scripts na página

Um pequeno código instalado na loja roda no navegador de cada comprador, registra quais scripts carregaram e reporta para um painel. É a abordagem mais próxima do que o requisito descreve, porque enxerga a sessão real, no aparelho real, com as extensões e a rede do próprio comprador.

O limite está no que o agente confere. Muitos só listam scripts e comparam com a lista aprovada. Se um script autorizado for alterado na origem, ou se a troca acontecer no conteúdo da página e não em um script, o agente precisa de uma segunda camada para perceber.

2. Monitor externo com visitas simuladas

Um robô do fornecedor abre a sua página de pagamento em intervalos regulares, registra o que carregou e compara com a visita anterior. Nada é instalado na loja, e a configuração leva minutos.

O ponto fraco é a amostra. O robô vê o que o robô vê: um endereço IP conhecido, um navegador padrão, uma sessão sem carrinho e sem login. Ataques que só disparam para compradores de certa região, em celular, ou depois do preenchimento do endereço passam despercebidos. E, entre uma visita e outra, a página fica sem vigilância.

3. Política CSP a partir da CDN ou do firewall de aplicação

A política de segurança de conteúdo (CSP) é um cabeçalho que diz ao navegador de quais origens a página pode carregar scripts. Alguns fornecedores de CDN e de firewall de aplicação oferecem a geração e o monitoramento dessa política como produto.

Funciona bem para bloquear origens desconhecidas. Não cobre alteração dentro de um script já permitido, exige que a loja passe a usar aquela CDN ou aquele firewall, e a política precisa de manutenção a cada novo fornecedor adicionado ao checkout. Para o 6.4.3, a CSP ajuda na parte de integridade, mas não substitui o inventário com justificativa.

4. Verificação do pagamento em si

Em vez de perguntar "quais scripts carregaram", essa abordagem pergunta "o que o comprador está vendo é o que o servidor emitiu?". O QR Code, a chave Pix, a linha digitável, o endereço da carteira e o destino do formulário de cartão são conferidos contra o que a loja gerou. Se houver diferença, a ferramenta bloqueia e alerta.

A vantagem é cobrir o resultado do ataque independentemente de como ele entrou na página. O limite é que, sozinha, não atende ao 6.4.3: o inventário e a autorização de scripts precisam vir junto.

Sete perguntas para fazer a qualquer fornecedor

1. Quais meios de pagamento são cobertos? Peça a lista: cartão de crédito, cartão de débito, Pix, boleto, carteiras digitais, stablecoins. Uma resposta genérica como "toda a página" costuma significar "só scripts".
2. A ferramenta observa sessões reais ou simuladas? Sessões reais mostram o que cada comprador viu. Sessões simuladas mostram o que o robô viu.
3. Ela bloqueia automaticamente ou só alerta? O 11.6.1 exige alerta. Bloquear é o que evita o prejuízo. Pergunte o que acontece nos minutos entre o alerta e a ação da sua equipe.
4. Exige que eu use a CDN ou o firewall do fornecedor? Trocar de infraestrutura por causa de um requisito costuma custar mais do que a ferramenta.
5. Que relatório é entregue para o QSA? Peça um exemplo real: inventário com responsável e justificativa, histórico de alterações, alertas emitidos e tratados.
6. O que acontece entre uma avaliação e outra? O requisito aceita verificação semanal, mas o ataque não espera. Pergunte qual é o intervalo real de detecção.
7. Quem opera a ferramenta no dia a dia? Quantas horas por mês a sua equipe vai gastar aprovando scripts, revisando alertas e mantendo listas. Essa conta define o custo verdadeiro.

Erros comuns

• Comprar inventário e achar que acabou. O 6.4.3 pede inventário; o 11.6.1 pede detecção e alerta. São entregas diferentes.
• Tratar o requisito como assunto só de cartão. O mesmo script que copia cartão troca QR Code. Deixar Pix e boleto de fora é deixar a porta aberta.
• Planejar a checagem semanal e descobrir o ataque no sexto dia. O intervalo da análise de risco é o mínimo aceitável, não o alvo.
• Confundir antifraude com integridade da página. O antifraude avalia se o comprador é legítimo. Os requisitos tratam de a página ser legítima.
• Aceitar prints e planilhas como evidência. O QSA quer histórico, com datas, responsáveis e justificativas.
• Escolher pelo preço do plano e esquecer o custo de operação. Uma ferramenta barata que exige um analista dedicado sai cara.

Como o Proteside se encaixa

O Proteside entra na página com uma linha de código, sem troca de CDN ou de plataforma. A cada sessão real de compra, confere o QR Code, a chave Pix, a linha digitável do boleto e o endereço da carteira com o que o servidor da loja emitiu, e bloqueia a troca antes de o comprador pagar. Ao mesmo tempo, mantém o inventário dos scripts da página de pagamento, registra autorizações e justificativas e exporta a evidência dos requisitos 6.4.3 e 11.6.1 com histórico.

Para ver como cada abordagem se compara ponto a ponto, com fatos públicos e data de consulta, acesse a página de comparativos.