Resumo: checklist prático de conformidade PCI DSS 6.4.3 para scripts de pagamento
- A maioria das equipes trata Subresource Integrity como a resposta ao 6.4.3. Sozinho não basta: SRI não inventaria todos os scripts automaticamente, não se aplica a scripts carregados dinamicamente e não detecta mudanças de comportamento em um script autorizado, que é o vetor principal de ataques Magecart.
- 6.4.3 é obrigatório desde 31 de março de 2025 e cobre bundles first-party, tags de terceiros, pixels de analytics, widgets de chat e bibliotecas de CDN. O cside PCI Shield é implantado como uma única tag de script na página de pagamento, e a maioria das equipes conclui a integração técnica em menos de 30 minutos.
- Se seu checkout roda um punhado de scripts estáticos, SRI mais CSP pode aguentar como controles de base. Se um gerenciador de tags injeta scripts dinamicamente, adicione monitoramento de integridade em runtime, o cside é validado pela VikingCloud para 6.4.3 e 11.6.1.
O Requisito 6.4.3 da PCI DSS 4.0.1 pede-lhe que faça três coisas para cada script que corre numa página de pagamento: confirmar que está autorizado, manter uma justificação escrita para o motivo da sua presença e protegê-lo com um controlo de integridade que apanhe alterações não autorizadas. O requisito é obrigatório desde 31 de março de 2025 e abrange código próprio (first-party), tags de terceiros (third-party), pixels de analítica, widgets de chat e tudo o resto que se execute no contexto de uma página de pagamento.
Existe para dar resposta ao skimming de páginas de pagamento, os ataques ao estilo Magecart em que JavaScript malicioso é introduzido numa página de checkout para recolher os dados dos cartões à medida que os clientes os digitam. O Requisito 6.4.3 é um de dois novos controlos do lado do cliente na PCI DSS 4.0.1, e o seu companheiro, o 11.6.1, trata do lado da monitorização. Esta checklist percorre o que a 6.4.3 exige e como lá chegar.
O que o Requisito 6.4.3 realmente exige
O PCI Security Standards Council define três controlos específicos no âmbito do Requisito 6.4.3:
1. Um método para confirmar que cada script está autorizado. Precisa de autorização documentada para cada script presente nas páginas de pagamento. Isso significa não apenas os scripts que a sua equipa escreveu, mas cada tag de terceiros, pixel de analítica, widget de chat, ferramenta de testes A/B e biblioteca carregada de CDN que corre no contexto de uma página de pagamento. Autorizar significa que sabe que o script está lá e que tem uma razão de negócio para ele.
2. Um método para garantir a integridade de cada script. Cada script tem de estar protegido contra modificações não autorizadas. Pode fazê-lo com hashes de Subresource Integrity (SRI) para scripts carregados externamente, controlos de Content Security Policy ou uma ferramenta de monitorização em tempo de execução que alerta quando o conteúdo ou o comportamento de um script muda. A SRI por si só não abrange scripts carregados dinamicamente ou servidos por CDNs cujo conteúdo roda sem que o URL mude.
3. Uma justificação escrita para cada script. Cada script autorizado precisa de uma razão de negócio documentada para estar na página de pagamento. Uma tag que só está presente porque o marketing a adicionou há três anos e ninguém a removeu não tem justificação. O seu avaliador vai pedir esta documentação.
O requisito companheiro, o 11.6.1, acrescenta a deteção de alterações e adulterações: um mecanismo automatizado que alerta quando os scripts das páginas de pagamento ou os cabeçalhos HTTP são modificados. Em conjunto, a 6.4.3 e a 11.6.1 exigem tanto um inventário estático com controlos de integridade como uma capacidade de monitorização em direto.
Passo 1: inventarie cada script nas suas páginas de pagamento
Comece com uma auditoria completa de cada script que carrega na página de pagamento. Essa lista inclui:
- Scripts próprios (first-party) que a sua equipa controla
- Tags de terceiros carregadas através de gestores de tags (Google Tag Manager, Tealium, Segment)
- Pixels de analítica (Google Analytics, Meta Pixel, quaisquer tags de atribuição de marketing)
- Widgets de chat e de suporte (Intercom, Drift, Zendesk)
- Scripts de testes A/B e de personalização
- Ferramentas de deteção de fraude
- Quaisquer bibliotecas carregadas de CDN
A maioria das equipas surpreende-se com a quantidade de scripts que corre efetivamente nas páginas de pagamento. Os gestores de tags são o suspeito habitual, carregando scripts extra que nunca passaram por uma revisão de segurança. Uma ferramenta de monitorização que descobre e lista cada script presente é a forma mais rápida de construir um inventário rigoroso.
Passo 2: autorize e justifique cada script
Para cada script no inventário, registe:
- Quem autorizou o script nesta página
- O objetivo de negócio que cumpre
- Se a página de pagamento é o âmbito certo para ele (muitos scripts de analítica não precisam de correr nas páginas de pagamento e devem ser excluídos)
Qualquer script que não consiga apresentar uma justificação de negócio clara deve ser retirado da página de pagamento. Menos scripts significa uma menor carga de conformidade e uma superfície de ataque mais pequena.
Passo 3: implemente controlos de integridade
Para cada script autorizado, coloque um mecanismo de integridade em funcionamento. As suas opções:
Subresource Integrity (SRI). Para scripts carregados a partir de URLs externos, um hash SRI na tag do script indica ao navegador que rejeite o script se o seu conteúdo tiver mudado. A SRI funciona bem para scripts servidos a partir de URLs de CDN estáveis e com versão. Não ajuda com scripts carregados dinamicamente, scripts cujo conteúdo muda sem que o URL mude, nem com scripts inline.
Content Security Policy. Uma lista de permissões (allowlist) de CSP impede o carregamento de scripts não autorizados. Não apanha alterações de comportamento num script que já está na lista de permissões.
Monitorização de integridade em tempo de execução. Uma ferramenta que observa o comportamento dos scripts em tempo real apanha o caso em que um script autorizado começa a fazer algo novo, como ler um campo de formulário em que nunca tinha tocado ou chamar um endpoint que nunca tinha chamado. Essa alteração de comportamento é o vetor Magecart, e é aquele que a SRI e a CSP não detetam.
Para uma cobertura completa da 6.4.3 e da 11.6.1, a monitorização em tempo de execução é a camada que faz o trabalho. A SRI e a CSP são controlos de base que assentam por baixo dela.
Como a cside cumpre tanto a 6.4.3 como a 11.6.1
O cside PCI Shield usa uma única tag de script na página de pagamento e depois:
- Descobre e inventaria cada script presente, atualizado continuamente
- Observa o comportamento de cada script em tempo real e alerta quando esse comportamento muda
- Produz a evidência de que uma avaliação PCI precisa: um inventário de scripts com o estado de autorização, além de eventos de deteção de adulteração com marcas temporais
A cside é validada pela VikingCloud para os Requisitos 6.4.3 e 11.6.1 da PCI DSS 4.0.1. Essa validação significa que um avaliador de segurança qualificado analisou a ferramenta e confirmou que cumpre os requisitos de evidência específicos de ambos os controlos, não apenas a sua intenção geral.
Leituras adicionais
- cside PCI Shield: inventário contínuo de scripts e monitorização em tempo de execução para páginas de pagamento
- Porque é que os crawlers não ajudam (sozinhos) na conformidade PCI
- Porque é que a CSP não funciona
- Visão geral da conformidade PCI DSS
