Scripts de terceiros na página de pagamento: o que o PCI DSS pede

Cada script que roda na página de pagamento (chat, análise de tráfego, gerenciador de tags, avaliações, pixels de marketing) consegue, em princípio, ver o que o cliente digita. Por isso o PCI DSS exige, no requisito 6.4.3, um inventário de todos esses scripts com justificativa, um método para autorizar cada um e outro para garantir que não foram alterados; e, no 11.6.1, um mecanismo que detecte mudanças na página como o cliente a recebe e alerte a equipe, pelo menos uma vez por semana. As duas regras passaram a ser obrigatórias em 31 de março de 2025.

Por que os scripts de terceiros são o elo fraco

Um script de terceiro não fica no seu servidor: o navegador do cliente o busca, a cada visita, no servidor do fornecedor. Se esse fornecedor for invadido ou mudar o arquivo, a sua página muda junto, sem que a sua equipe tenha publicado nada. O guia do PCI Security Standards Council sobre segurança da página de pagamento, de março de 2025, lembra ainda que esses scripts podem carregar outros, de parceiros do parceiro, e cita ferramentas de análise, marketing, gerenciamento de tags, validação de formulário e até de pagamento entre as que podem ser manipuladas para capturar dados.

Um estudo de caso da Visa mostra o efeito multiplicador. A investigação começou com um alerta de um banco sobre um único restaurante, mas o código malicioso estava num arquivo legítimo do fornecedor de pedidos online, e não no site do restaurante. O mesmo arquivo era usado por muitos dos mais de 1.500 clientes do fornecedor, e um terço deles foi comprometido. A Visa encontrou a origem dez dias depois da infecção.

O que o PCI DSS pede, em linguagem simples

Requisito 6.4.3: inventário, autorização e integridade

Todo script carregado e executado no navegador do cliente na página de pagamento precisa de três coisas:

• Autorização: um método para confirmar que cada script foi aprovado. A norma não diz como nem por quem; segundo o guia do PCI SSC, a aprovação pode ocorrer antes da inclusão ou da mudança, ou o quanto antes depois dela, já que o fornecedor pode alterar o arquivo sem avisar.
• Integridade: um método para garantir que o script não contém conteúdo não autorizado, tanto ao entrar quanto a cada atualização.
• Inventário: a lista de todos os scripts, com a justificativa de negócio ou técnica de cada um. Em ambientes simples, diz o guia, uma planilha pode bastar.

Os scripts de autenticação 3-D Secure estão dispensados dessa validação. E um fornecedor de scripts que nada têm a ver com pagamento pode não ser tratado como prestador de serviço para outros fins da norma, mas os scripts dele continuam sujeitos ao 6.4.3 e ao 11.6.1.

Requisito 11.6.1: detectar mudanças

É preciso ter um mecanismo que avise a equipe sobre alterações não autorizadas (scripts que surgem, mudam ou desaparecem e mudanças em cabeçalhos de segurança) na página tal como o navegador do cliente a recebe. A verificação deve rodar pelo menos semanalmente ou numa frequência definida por análise de risco. O próprio PCI SSC recomenda monitoramento frequente ou em tempo real quando possível, porque uma alteração maliciosa pode agir sem ser vista entre uma verificação e outra.

Como montar o inventário na prática

1. Mapeie as páginas. Inclua a página que exibe o formulário do provedor de pagamento. Em sites de página única, em que o navegador não recarrega entre as etapas, os scripts carregados antes continuam ativos no pagamento, e o guia trata todas as telas como parte do escopo.
2. Liste o que o navegador recebe, não só o que está no código: abra a página como cliente, porque gerenciadores de tags acrescentam scripts na hora.
3. Documente cada script: endereço de origem, fornecedor, responsável interno, finalidade, justificativa, quem autorizou e quando.
4. Decida: fica, sai ou vai para outra página. Script sem justificativa sai.
5. Escolha como garantir a integridade: política de origens permitidas, verificação da assinatura do arquivo ou ferramenta especializada. O PCI DSS não impõe um método.
6. Registre o comportamento esperado: quais campos o script precisa ler e para onde ele envia dados.
7. Revise a cada mudança, inclusive as que o fornecedor faz sozinho.

O que pode dar errado

• A planilha envelhece. Um inventário que ninguém atualiza vira uma foto antiga da página.
• Aprovar o fornecedor, não a versão. O arquivo muda no servidor dele, e a aprovação antiga não cobre o código novo.
• Esquecer a página ao redor do formulário. Usar o formulário do provedor reduz o escopo, mas a página que o exibe continua sendo sua responsabilidade.
• Alerta sem dono. Se o mecanismo só avisa e não bloqueia, o PCI SSC lembra que a resposta precisa ser rápida; defina quem recebe e quem age.
• Tratar o mínimo como meta. Uma checagem semanal deixa dias de exposição.

O Proteside gera essa evidência enquanto protege: registra os scripts autorizados na página de pagamento, confere no navegador do comprador o que muda e para onde os dados vão, e bloqueia o que não deveria estar ali. Veja como funciona a solução para conformidade com o PCI DSS ou a proteção para pagamentos com cartão, e teste grátis por 14 dias.