PCI DSS 4.0: os requisitos 6.4.3 e 11.6.1 para scripts no checkout

Aviso: este texto explica o padrão PCI DSS e as publicações oficiais do PCI Security Standards Council. Não é parecer de conformidade nem substitui o assessor qualificado (QSA) ou o adquirente.

O PCI DSS v4.0.1 tem dois requisitos para o JavaScript que roda na página de pagamento de uma loja virtual. O 6.4.3 pede que cada script dessa página seja autorizado, tenha a integridade verificada e conste de um inventário com justificativa. O 11.6.1 pede um mecanismo que detecte e alerte sobre mudanças não autorizadas nos cabeçalhos HTTP que afetam a segurança e no conteúdo dos scripts da página, como o navegador do cliente os recebe, pelo menos uma vez por semana ou na frequência definida numa análise de risco. Os dois deixaram de ser boa prática e passaram a ser obrigatórios em 31 de março de 2025. Para o lojista que valida pelo SAQ A, o PCI SSC trocou os dois requisitos, em 2025, por um critério de elegibilidade sobre ataques de script.

O escopo deste texto é o PCI DSS v4.0.1 (junho de 2024), a versão em vigor que consegui confirmar em outubro de 2026, e as publicações do PCI SSC sobre o SAQ A de janeiro e fevereiro de 2025. As citações do padrão são traduções livres; o texto que vale é o original em inglês, na biblioteca de documentos do PCI SSC. Para o contexto mais amplo de segurança do site, veja o guia de segurança básica de um site.

Por que esses requisitos existem

Uma página de pagamento costuma carregar scripts de várias origens: o próprio site, bibliotecas em CDN, analytics, gerenciadores de tags. A orientação do 6.4.3 explica que scripts aparentemente inofensivos podem ser usados para carregar código malicioso que lê os dados do cartão no navegador do cliente e os envia para fora. Esse ataque é chamado de e-skimming. O 11.6.1 parte da mesma premissa e acrescenta que, como as páginas são montadas no navegador a partir de várias fontes, o único lugar para notar a alteração é a página como o navegador a recebe (PCI DSS v4.0.1, requisitos 6.4.3 e 11.6.1, colunas de orientação).

Versões e datas

Sobre a data de vigência do novo SAQ A há uma pequena divergência entre os textos do PCI SSC: o anúncio de janeiro fala em 31 de março de 2025, e o post de fevereiro sobre a FAQ fala em 1º de abril de 2025.

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

Todos os scripts carregados e executados no navegador do cliente na página de pagamento precisam ser gerenciados assim (PCI DSS v4.0.1, requisito 6.4.3, tradução livre):

• há um método para confirmar que cada script é autorizado;

• há um método para assegurar a integridade de cada script;

• há um inventário de todos os scripts, com justificativa escrita, de negócio ou técnica, de por que cada um é necessário.

As notas de aplicabilidade e a orientação acrescentam pontos práticos:

• O requisito vale para scripts do próprio ambiente e para scripts de terceiros e de "quartos" (os que um script de terceiro carrega).

• Se a sua página incorpora o formulário de pagamento de um provedor (por exemplo, num iframe), o requisito vale para os scripts da sua página. Os scripts de dentro do formulário do provedor são responsabilidade dele, e a orientação diz que o lojista deve esperar do provedor a evidência de que ele cumpre o requisito.

• A autorização pode ser manual ou por um fluxo automatizado. Quando não for viável autorizar antes de um script mudar, a autorização deve ser confirmada o quanto antes depois da mudança.

• Os exemplos de mecanismo de integridade citados são SRI, CSP e sistemas de gerenciamento de scripts ou tags que impeçam a execução de código malicioso. A lista não é fechada.

• Para páginas de pagamento carregadas num iframe, a orientação sugere usar a CSP da página principal para restringir de onde o iframe pode ser carregado.

Na revisão 4.0.1, o PCI SSC esclareceu que a justificativa do inventário pode ser de negócio ou técnica, incluiu as três notas sobre iframes e a orientação para autorizar depois da mudança quando não der para autorizar antes (Summary of Changes v4.0 para v4.0.1, agosto de 2024).

O requisito 11.6.1: detecção de mudança e adulteração

O 11.6.1 pede um mecanismo de detecção de mudança e adulteração que (PCI DSS v4.0.1, requisito 11.6.1, tradução livre):

• alerte a equipe sobre modificações não autorizadas, incluindo indicadores de comprometimento, mudanças, inclusões e exclusões, nos cabeçalhos HTTP que afetam a segurança e no conteúdo dos scripts das páginas de pagamento, como recebidos pelo navegador do cliente;

• avalie os cabeçalhos e a página como recebidos;

• rode pelo menos uma vez por semana, ou na frequência definida na análise de risco direcionada da empresa, feita conforme o requisito 12.3.1.

A versão 4.0 falava em "cabeçalhos HTTP e conteúdo das páginas" e em "uma vez a cada sete dias". A 4.0.1 restringiu o alvo aos cabeçalhos que afetam a segurança e ao conteúdo dos scripts, e trocou o prazo por "semanal" (Summary of Changes v4.0 para v4.0.1). O padrão não lista quais cabeçalhos são esses; a CSP é o caso mais evidente, porque a própria orientação diz que uma mudança na CSP pode indicar adulteração.

As notas de aplicabilidade deixam claro que a intenção não é instalar software no computador ou no navegador do cliente, e sim usar técnicas como as dos exemplos. Os exemplos da orientação, que podem ser combinados (PCI DSS v4.0.1, 11.6.1):

• relatórios de violação da CSP enviados pelas diretivas report-to ou report-uri;

• monitorar mudanças na própria CSP;

• monitoramento externo por sistemas que pedem e analisam as páginas (monitoramento sintético) e alertam sobre mudanças no JavaScript;

• um script de detecção, resistente a adulteração, embutido na página, que alerta e bloqueia comportamento malicioso;

• proxies reversos e CDNs que detectam mudanças nos scripts.

O padrão avisa que essa lista não é completa e que nenhum desses mecanismos, sozinho, é necessariamente uma solução completa de detecção e alerta.

A quem se aplica

O PCI DSS vale para todas as entidades que armazenam, processam ou transmitem dados de cartão, ou que podem afetar a segurança desses dados: lojistas, processadores, adquirentes, emissores e outros provedores. Quem precisa validar a conformidade, e de que forma, é decidido por quem administra os programas de conformidade, como as bandeiras e os adquirentes (PCI DSS v4.0.1, introdução). A tabela resume como os dois requisitos se encaixam em cada forma de integrar o pagamento, segundo o padrão e a FAQ 1588. Qual questionário (SAQ) ou relatório o seu caso usa é definido com o adquirente.

O que mudou no SAQ A em 2025

O SAQ A é o questionário de autoavaliação mais curto, usado por lojistas que terceirizam todo o tratamento dos dados de cartão. Em janeiro de 2025 o PCI SSC anunciou uma nova versão do SAQ A para PCI DSS v4.0.1 que (PCI SSC, 30/01/2025):

• removeu do questionário os requisitos 6.4.3 e 11.6.1, além do 12.3.1, a análise de risco que apoia o 11.6.1;

• incluiu um critério de elegibilidade: o lojista confirma que o site não está suscetível a ataques de scripts que possam afetar seus sistemas de comércio eletrônico.

O próprio Conselho deixa claro que a mudança é só na forma de reportar no SAQ A, e que ela não remove os requisitos do padrão. Nas palavras do anúncio, as mudanças "do not remove or diminish the underlying requirements within PCI DSS".

A FAQ 1588, de fevereiro de 2025, explica como cumprir o critério (FAQ 1588; post do PCI SSC sobre a FAQ):

• O critério vale para lojistas cuja página incorpora o formulário de pagamento de um provedor, por exemplo num iframe. Não vale para quem redireciona o cliente ao provedor nem para quem terceiriza todo o pagamento.

• Há dois caminhos: usar técnicas como as dos requisitos 6.4.3 e 11.6.1, aplicadas pelo próprio lojista ou por um terceiro; ou obter do provedor de pagamento, que precisa estar em conformidade com o PCI DSS, a confirmação de que a solução dele, implementada conforme as instruções, protege a página do lojista contra ataques de script.

• Um fornecedor de scripts que não têm relação com o pagamento e não podem afetar a segurança dos dados de cartão não é considerado provedor de serviço (TPSP) para fins do SAQ A.

• O lojista deve confirmar com o adquirente ou com as bandeiras se precisa enviar um SAQ e qual.

Quem valida por outros questionários ou por relatório de assessor continua respondendo pelos dois requisitos. No SAQ A-EP da versão 4.0, por exemplo, o 6.4.3 e o 11.6.1 aparecem com as mesmas exigências (SAQ A-EP v4.0). Confira a versão vigente do questionário na biblioteca de documentos do PCI SSC antes de responder.

Como implementar na prática

Os passos abaixo são uma recomendação de organização do trabalho, baseada nos exemplos do próprio padrão. Não são um procedimento oficial do PCI SSC, e a forma de evidenciar cada item deve ser combinada com o assessor.

1. Mapeie as páginas de pagamento: a página com o formulário de cartão e, se o formulário é de um provedor em iframe, a página do lojista que o incorpora. Inclua variações (mobile, idiomas, testes A/B).

2. Monte o inventário. Para cada script: endereço, origem (próprio, terceiro, carregado por terceiro), finalidade, justificativa, responsável interno e data de aprovação. Scripts sem justificativa saem da página.

3. Defina o processo de autorização. Pode ser um item na revisão de código ou um fluxo de aprovação no gerenciador de tags. Para scripts que o fornecedor muda sem aviso, registre a confirmação logo depois da mudança, como a orientação admite.

4. Aplique controles de integridade. SRI (atributo integrity) serve para arquivos estáticos e versionados: o navegador recusa o arquivo se o conteúdo mudar (MDN: SRI). Para o restante, uma CSP limita de onde a página carrega scripts e para onde pode enviar dados, e a diretiva frame-src limita de onde o iframe de pagamento pode vir. Detalhes no artigo sobre cabeçalhos HTTP de segurança.

5. Implante a detecção do 11.6.1: relatórios de violação da CSP, comparação periódica dos cabeçalhos e dos scripts recebidos com a versão aprovada, ou outro mecanismo da lista do padrão. Se a frequência for menor que semanal ou diferente dela, documente a análise de risco do 12.3.1.

6. Defina quem recebe os alertas e o que fazer com eles: confirmar se a mudança foi autorizada, atualizar o inventário ou acionar o plano de resposta a incidentes.

7. Guarde evidências: inventário com histórico, aprovações, configuração dos mecanismos e registros de alertas tratados.

Um exemplo de CSP para a página do lojista que incorpora o formulário de um provedor. Os domínios são fictícios; use os que o seu provedor documenta.

Content-Security-Policy:
  script-src 'nonce-{gerado por resposta}' 'strict-dynamic';
  frame-src https://pagamento.provedor.exemplo;
  connect-src 'self' https://api.provedor.exemplo;
  form-action 'self' https://pagamento.provedor.exemplo;
  object-src 'none';
  base-uri 'none';
  report-to csp

Nessa política, o navegador só executa scripts com o nonce da resposta (e os que eles carregarem), só abre o iframe de pagamento no domínio do provedor, só faz chamadas de rede ao próprio site e à API do provedor e reporta as violações. Em lojas com muitos scripts de marketing, o connect-src restrito costuma ser o ponto que mais exige ajuste.

Limites de cada controle

• SRI não funciona para scripts que o fornecedor atualiza no mesmo endereço: a cada atualização legítima, o hash deixa de bater e o navegador bloqueia o arquivo.

• Uma CSP com lista de domínios permite qualquer código vindo de um domínio liberado. Se o fornecedor liberado for comprometido, a política não impede o ataque.

• O monitoramento externo vê a página que o robô recebeu. Conteúdo que muda por país, dispositivo, cookie ou horário pode não aparecer na verificação.

• O padrão aceita checagem semanal, mas um ataque pode ficar ativo entre uma checagem e outra. A análise de risco do 12.3.1 serve justamente para decidir se a página pede mais frequência.

• Cumprir o 6.4.3 e o 11.6.1 não torna o resto do ambiente conforme ao PCI DSS, e uma ferramenta não substitui a avaliação do assessor ou o aceite do adquirente.

Como verificar o seu site

Para começar à mão, abra a página de pagamento com o DevTools, filtre a aba Network por JS e anote cada script, sua origem e quem o pediu (a coluna Initiator mostra isso). Depois confira os cabeçalhos da resposta com curl -sI e veja se há CSP.

Os planos pagos do WebVyze incluem um inventário dos scripts das páginas de checkout ligado aos requisitos 6.4.3 e 11.6.1, além de auditorias agendadas e alertas. O WebVyze só lê páginas públicas e nunca altera o site, então ele mostra o que um visitante recebe e não enxerga o que está dentro do iframe do provedor nem os seus processos internos de aprovação. Ele ajuda a montar e manter as evidências; não certifica conformidade com o PCI DSS.