Conformidade e Governação

PCI DSS 6.4.3 e 11.6.1: segurança dos scripts da página de pagamento

Os requisitos 6.4.3 e 11.6.1 do PCI DSS 4.0 explicados: inventário de scripts, autorização, integridade e alertas de adulteração, e como o Cloudflare Page Shield ajuda.

Os requisitos 6.4.3 e 11.6.1 do PCI DSS protegem as páginas de pagamento de comércio eletrónico contra scripts de skimming. O requisito 6.4.3 exige um método para confirmar que cada script de uma página de pagamento está autorizado, um método para garantir a sua integridade e um inventário de todos os scripts com uma justificação escrita para cada um. O requisito 11.6.1 exige um mecanismo de deteção de alterações e adulterações que alerte a sua equipa para alterações não autorizadas aos cabeçalhos HTTP com impacto na segurança e ao conteúdo dos scripts das páginas de pagamento, tal como o browser do consumidor os recebe. Ambos foram boas práticas até 31 de março de 2025 e são obrigatórios desde então. A client-side security da Cloudflare, anteriormente Page Shield, pode ajudar a cumpri-los, e a Vigilbase pode operá-la numa conta Managed Cloudflare.

O que exigem os requisitos 6.4.3 e 11.6.1 do PCI DSS?

Nas orientações do PCI Security Standards Council (PCI SSC), o 6.4.3 destina-se a prevenir ataques de skimming antes de acontecerem, e o 11.6.1 garante que as alterações não autorizadas são reconhecidas e geram alertas. Em conjunto, centram-se em que os scripts das páginas de pagamento sejam autorizados, verificados quanto à integridade e monitorizados contra adulteração, bem como nos cabeçalhos HTTP com impacto na segurança que protegem a página.

1.Autorização (6.4.3): um método confirma que cada script da página de pagamento está autorizado. As orientações do PCI SSC indicam que a autorização pode ocorrer antes de um script ser adicionado ou alterado, ou logo que possível após uma alteração.

2.Integridade (6.4.3): um método garante a integridade de cada script. O PCI DSS não impõe um mecanismo; as suas orientações dão como exemplos a Content Security Policy e a Subresource Integrity.

3.Inventário (6.4.3): um inventário de todos os scripts, com uma justificação escrita, de negócio ou técnica, para a necessidade de cada um. Abrange os scripts carregados a partir do seu próprio ambiente e de terceiros e quartos.

4.Deteção de adulteração (11.6.1): um mecanismo alerta o pessoal para modificações não autorizadas, incluindo indicadores de comprometimento, alterações, adições e eliminações, aos cabeçalhos HTTP com impacto na segurança e ao conteúdo dos scripts das páginas de pagamento, tal como recebidos pelo browser do consumidor.

5.Frequência (11.6.1): o mecanismo é executado pelo menos semanalmente, ou com a frequência definida numa análise de riscos direcionada nos termos do requisito 12.3.1. O PCI SSC recomenda uma monitorização frequente ou em tempo real, sempre que viável.

6.O 11.6.1 não exige que instale software nos dispositivos ou browsers dos seus clientes. Exige que detete atividade inesperada de scripts nas páginas que disponibiliza.

Quando passaram os requisitos 6.4.3 e 11.6.1 a ser obrigatórios?

O PCI DSS v4.0, publicado em março de 2022, introduziu ambos como novos requisitos que eram boas práticas até 31 de março de 2025. O PCI DSS v4.0.1, uma revisão limitada publicada em junho de 2024, acrescentou notas de aplicabilidade sobre os scripts das páginas de pagamento, mas não alterou essa data, e a v4.0 foi retirada a 31 de dezembro de 2024. Desde 31 de março de 2025, os requisitos 6.4.3 e 11.6.1 são obrigatórios e têm de ser plenamente considerados numa avaliação PCI DSS. O requisito 12.10.5 também prevê que o seu plano de resposta a incidentes abranja os alertas do mecanismo de deteção de alterações e adulterações das páginas de pagamento.

Que páginas e scripts estão abrangidos?

O âmbito depende da forma como o seu checkout recolhe os dados dos cartões. O suplemento informativo do PCI SSC de março de 2025 define quem é responsável por que scripts.

1.Se alojar o formulário de pagamento, é responsável por todos os scripts das suas páginas de pagamento. O prestador de serviços de pagamento é responsável pelos scripts que inclua para os seus próprios serviços.

2.Se incorporar o formulário de um prestador de serviços de pagamento num iframe, a página que o incorpora continua abrangida. É responsável pelos scripts dessa página principal; o prestador é responsável pelos scripts dentro do seu iframe.

3.Quando um script cria o iframe ou executa um redirecionamento, os requisitos 6.4.3 e 11.6.1 aplicam-se a esse script.

4.Numa aplicação de página única, os scripts permanecem em memória enquanto os clientes navegam entre vistas, pelo que os requisitos se aplicam a todas as vistas da aplicação, porque qualquer uma delas pode afetar o formulário de pagamento incorporado.

5.Para os comerciantes que utilizam uma solução 3-D Secure (3DS), os scripts 3DS não precisam de validação face ao 6.4.3. Qualquer script executado para outra finalidade precisa.

6.Se o prestador de serviços de pagamento tratar de toda a recolha de pagamentos, por exemplo através de uma ligação de pagamento no seu próprio website, o comerciante não tem nada a fazer quanto aos requisitos 6.4.3 e 11.6.1.

O que mudou para os comerciantes SAQ A?

O SAQ A do PCI DSS v4.0.1, na sua revisão r1, não inclui os requisitos 6.4.3 nem 11.6.1. Em vez disso, um comerciante cuja página web inclua um formulário de pagamento incorporado de um prestador de serviços de pagamento tem de confirmar que o seu website não é suscetível a ataques de scripts que possam afetar os seus sistemas de comércio eletrónico. A FAQ 1588 do PCI SSC indica que o comerciante pode confirmá-lo utilizando técnicas como as dos requisitos 6.4.3 e 11.6.1, implementadas pelo próprio ou por um terceiro, ou obtendo do seu prestador de serviços de pagamento em conformidade com o PCI DSS a confirmação de que a solução incorporada protege a página de pagamento contra ataques de scripts quando implementada de acordo com as instruções. O critério não se aplica a comerciantes que redirecionam os clientes para o prestador ou que externalizam totalmente os pagamentos. É o seu adquirente ou as marcas de pagamento que decidem que SAQ utiliza, e a FAQ 1331, datada de agosto de 2026, indica que os critérios de elegibilidade do SAQ não devem servir de guia para a aplicabilidade num Report on Compliance, salvo acordo com eles.

Que evidências procuram os avaliadores?

Os testes previstos para o 6.4.3 consistem em examinar as políticas e os procedimentos, entrevistar o pessoal responsável, examinar os registos de inventário e examinar as configurações dos sistemas. Para o 11.6.1, os avaliadores examinam as definições de sistema e de configuração do mecanismo, as páginas de pagamento monitorizadas e os resultados da monitorização, entrevistam o pessoal responsável e, se utilizar uma, examinam a análise de riscos direcionada. Um conjunto prático de evidências tem este aspeto:

1.Um inventário de scripts para cada página de pagamento e página principal, com um responsável e uma justificação de negócio ou técnica para cada script.

2.Registos de como cada script foi autorizado, incluindo alterações aprovadas logo que possível após terem ocorrido.

3.O método de integridade que utiliza, como uma lista de permissões Content Security Policy, hashes, Subresource Integrity ou monitorização de páginas, e a respetiva configuração.

4.A configuração da deteção de adulteração, que mostra que páginas e cabeçalhos com impacto na segurança são avaliados e com que frequência.

5.O histórico de alertas e o que foi feito em relação a cada alerta, ligado ao seu plano de resposta a incidentes.

6.Políticas, procedimentos, funções e responsabilidades documentados para os requisitos 6 e 11, e a análise de riscos direcionada, caso não faça a avaliação semanalmente.

Como ajuda a client-side security da Cloudflare (anteriormente Page Shield)

A Cloudflare mudou o nome do Page Shield para client-side security em março de 2026, e as políticas do Page Shield passaram a chamar-se content security rules. Com a monitorização ativa, a Cloudflare acrescenta um cabeçalho Content-Security-Policy-Report-Only a uma amostra das respostas HTML, e os browsers dos visitantes comunicam os scripts e as ligações que cada página carrega. A Cloudflare transforma esses relatórios numa lista dos scripts em execução nas suas páginas. A página da Cloudflare sobre o PCI DSS indica que, para ajudar com os requisitos 6.4.3 e 11.6.1, precisa do Client-Side Security Advanced, o antigo add-on Page Shield.

1.Inventário: a monitorização de scripts está disponível em todos os planos. Os planos Business e superiores acrescentam a monitorização de ligações e de cookies, a atribuição de páginas, que mostra onde um script apareceu pela primeira vez, e alertas para novos recursos e novos domínios.

2.Autorização: com o Advanced, as content security rules transformam a sua lista de permissões em cabeçalhos Content Security Policy. Uma regra com a ação Log comunica as violações sem bloquear; ao mudá-la para Allow, bloqueia os recursos que não estão na lista. As alterações às políticas do Page Shield, agora content security rules, ficam registadas nos registos de auditoria da Cloudflare.

3.Integridade: o Advanced acrescenta a deteção de alterações de código e a deteção de scripts e ligações maliciosos com base em informações sobre ameaças e aprendizagem automática. As content security rules suportam fontes hash, mas não nonces.

4.Alertas: os alertas de novos recursos e de alterações de código são enviados diariamente, ou de imediato quando configurados com um filtro de zona, e os alertas de novos domínios de hora a hora. O Advanced acrescenta alertas de recursos maliciosos. Os alertas seguem para e-mail, webhooks ou serviços de notificação ligados.

5.O Advanced permite ainda até cinco content security rules e quatro tarefas Logpush.

6.O que continua a seu cargo: a documentação da Cloudflare descreve a monitorização de scripts, ligações e cookies. O requisito 11.6.1 abrange também os cabeçalhos HTTP com impacto na segurança, pelo que deve acordar com o seu avaliador a forma de detetar alterações nos cabeçalhos. Alguém continua a ter de redigir a justificação de cada script e de atuar perante cada alerta.

Como a Vigilbase opera a client-side security por si

Numa conta Managed Cloudflare, a Vigilbase pode ativar a client-side security, construir o inventário de scripts com os seus programadores, executar as content security rules em modo Log até as violações estarem compreendidas e mudá-las para Allow com a sua aprovação. Os alertas de novos scripts, de alterações de código e de scripts maliciosos são investigados, e o registo mostra a investigação, a ação tomada e a verificação. A cobertura segue o seu pacote: o Core funciona em horário laboral, enquanto o Priority e o Critical funcionam 24/7. Se comprar Cloudflare Enterprise através da Vigilbase, inclua o Client-Side Security Advanced no âmbito da licença; a proposta confirma-o.

Responsabilidade e nota jurídica

A Vigilbase não torna a sua organização conforme com o PCI DSS e não é o seu avaliador. Ajuda-o a operar os controlos e a produzir evidências para os requisitos 6.4.3 e 11.6.1. Este guia resume publicações do PCI SSC e da Cloudflare tal como estavam disponíveis em outubro de 2026. Não constitui aconselhamento jurídico nem de conformidade: o seu Qualified Security Assessor, o seu adquirente ou as marcas de pagamento decidem como o PCI DSS se aplica a si.

Principais conclusões

✓O requisito 6.4.3 exige autorização, integridade e um inventário justificado para cada script executado numa página de pagamento.

✓O requisito 11.6.1 exige alertas sobre alterações não autorizadas aos cabeçalhos HTTP com impacto na segurança e aos scripts das páginas de pagamento, pelo menos semanalmente ou com a frequência definida por uma análise de riscos direcionada.

✓Ambos são obrigatórios desde 31 de março de 2025, e incorporar o iframe de um prestador de serviços de pagamento não retira a página principal do âmbito.

✓A client-side security da Cloudflare, anteriormente Page Shield, ajuda com estes requisitos quando tem o Client-Side Security Advanced.

✓As ferramentas produzem evidências; a sua equipa continua a justificar cada script, a aprovar alterações e a atuar perante os alertas.

Fontes

Obtenha um Cloudflare Checkup gratuito

Uma classificação de A a F para a sua conta Cloudflare em cerca de 2 minutos. Apenas leitura: inicie sessão com a Cloudflare e o acesso é revogado quando a verificação terminar. A classificação e as conclusões gratuitas não têm custo; o relatório completo é uma atualização opcional.

Executar o Checkup gratuito

Soluções relacionadas

Serviços Vigilbase relacionados com este guia

Perguntas frequentes

O que exige o requisito 6.4.3 do PCI DSS?

O requisito 6.4.3 do PCI DSS exige que cada script da página de pagamento carregado e executado no browser do consumidor seja gerido de três formas: um método confirma que cada script está autorizado, um método garante a integridade de cada script e um inventário de todos os scripts regista uma justificação escrita para a necessidade de cada um.Aplica-se aos scripts carregados a partir do seu próprio ambiente e de terceiros e quartos. Os avaliadores examinam as suas políticas e procedimentos, os registos de inventário e as configurações dos sistemas, e entrevistam os responsáveis.Como funciona uma firewall de aplicações web Guia prático de proteção de sites

O que exige o requisito 11.6.1 do PCI DSS?

O requisito 11.6.1 do PCI DSS exige um mecanismo de deteção de alterações e adulterações que alerte o pessoal para modificações não autorizadas aos cabeçalhos HTTP com impacto na segurança e ao conteúdo dos scripts das páginas de pagamento, tal como recebidos pelo browser do consumidor. Tem de ser executado pelo menos semanalmente, ou com a frequência definida numa análise de riscos direcionada.O seu plano de resposta a incidentes deve prever a forma de responder aos respetivos alertas. O PCI SSC recomenda uma monitorização frequente ou em tempo real, sempre que viável, porque uma alteração maliciosa pode passar despercebida entre verificações.Verificador de Cabeçalhos de Segurança HTTP Operação de WAF gerido e controlo de alterações

Os requisitos 6.4.3 e 11.6.1 aplicam-se se utilizarmos o iframe de um prestador de serviços de pagamento?

Sim, à página que incorpora o iframe. É responsável pelos scripts dessa página principal, e o prestador é responsável pelos scripts dentro do seu iframe. Se validar com o SAQ A, confirma antes que o seu website não é suscetível a ataques de scripts que possam afetar os seus sistemas de comércio eletrónico.A FAQ 1588 do PCI SSC permite a um comerciante SAQ A confirmá-lo com técnicas como as dos requisitos 6.4.3 e 11.6.1, ou com uma confirmação do seu prestador de serviços de pagamento em conformidade com o PCI DSS. É o seu adquirente ou as marcas de pagamento que decidem que SAQ se aplica.Verificação de segurança do site Guia prático de proteção de sites

O Cloudflare Page Shield é suficiente para o PCI DSS 4.0?

A Cloudflare indica que a client-side security, anteriormente Page Shield, pode ajudar com os requisitos 6.4.3 e 11.6.1 se tiver o Client-Side Security Advanced. Por si só, não os cumpre na totalidade: continua a ter de justificar cada script, aprovar alterações, abranger os cabeçalhos HTTP com impacto na segurança e responder aos alertas, e é o seu avaliador que decide se as evidências são suficientes.O licenciamento Cloudflare Enterprise explicado Cloudflare Enterprise com a Vigilbase

A Vigilbase pode operar a client-side security da Cloudflare por nós?

Sim, no âmbito de um pacote Managed Cloudflare. A Vigilbase pode ativá-la, construir o inventário de scripts com os seus programadores, passar as content security rules de Log para Allow com a sua aprovação e investigar os alertas, com um registo da ação tomada e da respetiva verificação.O Core abrange o horário laboral; o Priority e o Critical funcionam 24/7. A Vigilbase não torna a sua organização conforme com o PCI DSS e não substitui o seu avaliador.Compare Core, Priority e Critical Cobertura e compromissos de resposta a incidentes

Tópicos Relacionados

Segurança de rede

Pronto para melhorar a sua segurança?

A nossa equipa pode ajudá-lo a implementar as medidas de segurança discutidas neste guia. Obtenha orientação especializada adaptada à sua organização.

Começar agora Continuar a aprender