Os requisitos PCI DSS 4.0.1 6.4.3 e 11.6.1 governam os scripts e cabeçalhos HTTP nas suas páginas de pagamento. O 6.4.3 faz você inventariar, autorizar e assegurar a integridade de cada script. O 11.6.1 faz você detectar e alertar sobre mudanças não autorizadas nos scripts e cabeçalhos de segurança daquela página. Ambos são obrigatórios desde 2025-03-31. Este guia decompõe cada cláusula, o que ela significa para a página em produção, e a evidência específica que um QSA espera que ela produza.
Esses dois requisitos existem por causa de e-skimming. Atacantes no estilo Magecart não vazam seu servidor. Eles alteram um script que o navegador carrega e então capturam dados de titular de cartão direto do formulário enquanto o usuário digita. Um iframe de processador não cobre a página que o enquadra. cside vive exatamente nessa lacuna: registra cada script que navegadores reais executam na página de pagamento, captura autorização, e sinaliza mudanças de integridade e de cabeçalho conforme elas acontecem.
O que o requisito 6.4.3 de fato exige
O 6.4.3 estabelece três obrigações para todo script de página de pagamento. Leia cada uma como uma cláusula separada, porque um QSA fará isso:
- Um método confirma que cada script está autorizado antes de carregar ou executar.
- Um método assegura a integridade de cada script.
- Um inventário de scripts é mantido com uma justificativa escrita de por que cada um é necessário.
"Autorizado" e "necessário" são as duas palavras que fazem as equipes tropeçar. Autorização é uma decisão registrada: um aprovador nomeado assinou que este script pode rodar em uma página no escopo de dados de titular de cartão. Justificativa é a razão de negócio pela qual ele existe. Um pixel de tracking que o marketing adicionou no trimestre passado geralmente não tem nenhum dos dois, exatamente o tipo de achado que o 6.4.3 expõe.
O escopo é mais amplo do que código first-party. O controle cobre todo script que o navegador executa na página: seus próprios bundles, SDKs de terceiros, e os scripts de quarta parte que esses vendors puxam em runtime. Um tag manager que injeta mais três scripts após o carregamento da página são mais três entradas no seu inventário, e essas entradas mudam sem um deploy do seu lado.
O PCI SSC lista hashes Subresource Integrity (SRI) e Content-Security-Policy como mecanismos de integridade de exemplo. Eles valem para assets estáticos. Quebram no momento em que um script é dinâmico. Uma tag de analytics ou ferramenta A/B que se atualiza legitimamente invalida o hash, então um SRI fixado ou bloqueia uma atualização boa ou é removido e deixa de proteger qualquer coisa. A Content Security Policy tem o mesmo limite: ela não consegue garantir o que um script permitido faz em runtime. É por isso que a integridade para páginas de pagamento reais tem que ser avaliada sobre o que executou, não sobre um hash definido em build time.
O que o requisito 11.6.1 de fato exige
O 11.6.1 é um controle de detecção, não de gestão. Ele exige um mecanismo de detecção de mudança e adulteração que faz duas coisas:
- Alerta o pessoal sobre modificação não autorizada (incluindo indicadores de comprometimento, mudanças, adições e remoções) dos cabeçalhos HTTP e do conteúdo de páginas de pagamento conforme recebidos pelo navegador do consumidor.
- Avalia os cabeçalhos e o conteúdo recebidos numa frequência definida pela sua targeted risk analysis sob o requisito 12.3.1, ou ao menos uma vez a cada sete dias.
A frase "conforme recebidos pelo navegador do consumidor" carrega o requisito. O 11.6.1 não está perguntando o que seu CDN serviu ou o que seu repo contém. Ele pergunta o que o navegador renderizou, após cada redirecionamento, injeção, e modificação em runtime. Um skimmer lê navigator.webdriver, propriedades de automação ausentes, e a ausência de interação real para reconhecer um scanner, e então serve código limpo para ele e o payload para um humano. Um controle que só vê a versão escaneada nunca dispara.
Cabeçalhos HTTP estão no escopo porque são uma superfície de ataque, não um detalhe de configuração. Um cabeçalho Content-Security-Policy enfraquecido ou removido permite que um script malicioso carregue, exatamente o que a política deveria bloquear. O 11.6.1 quer que você perceba que o cabeçalho mudou, e que perceba na resposta entregue, não na sua configuração de origem.
Como os dois requisitos dividem o trabalho
O 6.4.3 governa o que você permite; o 11.6.1 governa o que aconteceu na página.
| Pergunta | Requisito | O que governa | Modo de falha que captura |
|---|---|---|---|
| Quais scripts são permitidos aqui, e por quê? | 6.4.3 | Autorização, justificativa, integridade, inventário | Um script no escopo sem aprovação ou documentação |
| A página ou seus cabeçalhos mudaram sem aprovação? | 11.6.1 | Detecção e alerta sobre mudanças de script e cabeçalho | Uma adulteração ao vivo que o inventário nunca notou |
| Com que frequência checamos a página entregue? | 11.6.1 + 12.3.1 | Frequência, com piso de sete dias | Checagens desatualizadas que perdem mudanças transitórias |
Trate-os como um ciclo, não como dois projetos. Um inventário sem detecção ao vivo é uma lista que fica desatualizada no momento em que um vendor publica uma atualização. Detecção sem inventário produz alertas que ninguém consegue triar, porque não há baseline de como "autorizado" se parece.
A evidência que cada controle precisa produzir
Um QSA avalia a conformidade a partir de artefatos. Mapeie cada cláusula ao registro que ela gera para que você possa entregar exatamente o que ele pede.
| Cláusula | Artefato de evidência | O que precisa mostrar |
|---|---|---|
| Inventário 6.4.3 | Inventário de scripts vinculado a páginas no escopo | URL, responsável e última versão vista de cada script |
| Autorização 6.4.3 | Registro de aprovação por script | Quem aprovou, quando, e quais dados toca |
| Justificativa 6.4.3 | Nota de razão de negócio por script | Por que o script é necessário numa página de pagamento |
| Integridade 6.4.3 | Histórico de integridade | Como cada script é confirmado inalterado ao longo do tempo |
| Detecção 11.6.1 | Log de mudanças com alertas | Timestamp, diff, página e quem foi notificado |
| Avaliação de cabeçalhos 11.6.1 | Histórico de cabeçalhos por página | Valores de cabeçalhos de segurança e mudanças entre carregamentos |
| Frequência 11.6.1 | Análise de risco + cadência de checagem | A justificativa 12.3.1 e prova de que as checagens rodaram |
O artefato que mais falta às equipes é o histórico de integridade e o histórico de cabeçalhos ao longo do tempo. Um único snapshot prova que a página esteve limpa uma vez. Um QSA avaliando o 11.6.1 quer evidência de que você teria pego uma mudança: um registro com timestamp através de muitos carregamentos reais de página, não uma captura de tela.
Por que um processador não fecha isso por você
Uma suposição comum é que hospedar campos de pagamento em um iframe de Stripe, Adyen ou Braintree empurra o 6.4.3 e o 11.6.1 para o processador. Não empurra. O iframe é sandboxed, mas a página do comerciante que o enquadra não é. Seu analytics, ferramenta A/B, session-replay e widgets de chat rodam todos no mesmo contexto de navegador de nível superior, e um script ali pode ler o DOM, sobrepor um campo falso em cima do iframe, ou redirecionar o formulário no submit. A atualização do SAQ A de janeiro de 2025 estreitou a elegibilidade porque poucas páginas de pagamento reais estão livres de scripts de terceiros, e adicionou um critério de que você confirme que seu site não é suscetível a ataques baseados em scripts, o que é difícil de provar sem monitoramento. Os requisitos ficam com a página que você serve.
Por que a ameaça fica cada vez mais difícil de escanear
A razão pela qual o 11.6.1 insiste na página entregue é que o tooling do atacante é construído para derrotar qualquer coisa que não seja real. Navegadores headless e instrumentados vazam: uma flag navigator.webdriver, objetos chrome de runtime ausentes, artefatos Runtime do Chrome DevTools Protocol, e timing impossível marcam uma sessão como não humana. Skimmers fazem fingerprint desses sinais e ficam dormentes para crawlers e checagens sintéticas.
Tooling de evasão também avançou na outra direção. O relatório de pesquisa da cside sobre o futuro da segurança web constatou que playwright-stealth, automação ajustada para suprimir esses vazamentos, estava cerca de dez vezes mais usado ao final de 2025. A conclusão prática para 6.4.3 e 11.6.1: integridade e detecção de mudanças precisam rodar onde os dados de titular de cartão são de fato inseridos, na sessão real do navegador, não a partir de um ponto de vista externo que um script evasivo consiga identificar e se esconder.
Como cside produz essa evidência na camada do navegador
cside instrumenta a página de pagamento em navegadores reais, que é a superfície à qual ambos os requisitos apontam.
- Para o 6.4.3, ele captura o inventário completo de scripts, incluindo os scripts de quarta parte que os vendors puxam em runtime, registra autorização e justificativa ao lado de cada entrada, e mantém um histórico de integridade para que você prove que um script permaneceu intacto entre versões.
- Para o 11.6.1, monitora o conteúdo de scripts e os cabeçalhos HTTP de segurança na página entregue, faz diff entre carregamentos, e alerta sobre mudança não autorizada, com um registro com timestamp que responde à pergunta de frequência do 12.3.1 sem uma coleta manual semanal.
- Também expõe o payload de runtime de cada script e vincula o comportamento do script a sinais de dispositivo, IP real e VPN/proxy, para que uma mudança sinalizada venha com contexto em vez de um mero descompasso de hash.
Como observa o que executou em vez do que foi mostrado a um scanner, cside captura a mesma evidência de navegador que um atacante de e-skimming tenta esconder. Isso alinha o fluxo de conformidade com a ameaça real. Para o rollout operacional e a visão de relatório para QSA, os guias abaixo vão mais fundo.
Leitura adicional na cside
- Como cumprir PCI 6.4.3 e 11.6.1
- O que QSAs procuram ao avaliar 6.4.3 e 11.6.1
- Comparação de soluções para PCI DSS 6.4.3 e 11.6.1
- O que é client-side security
- cside PCI Shield
- A forma mais rápida de cumprir PCI DSS 6.4.3 e 11.6.1
- PCI SSF ou PCI DSS: qual norma se aplica ao seu caso
A partir de 2026-06-18, trate isto como orientação operacional, não aconselhamento jurídico. Confirme a linguagem exata do controle com seu QSA, assessoria jurídica ou responsável por risco.
