Neste Blog:
- O que os auditores buscam no PCI 6.4.3 e 11.6.1
- Exemplos de ataques e multas
- Comparação de soluções de fornecedores
- Recursos para sua equipe (checklists, avaliações)
O PCI 6.4.3 e 11.6.1 trata de uma coisa: controle e visibilidade sobre o que é executado no navegador do seu usuário. Especificamente nas páginas de pagamento. Esses requisitos obrigam as empresas a finalmente entender o que está acontecendo no lado do cliente: Quais scripts estão sendo carregados? Foram aprovados? Estão se comportando de forma suspeita? Surpreendentemente, a maioria das equipes não tem respostas para essas perguntas. Elas nunca realmente precisaram ter. E agora essas equipes estão correndo para se adequar às auditorias do PCI DSS 4.0.1. De acordo com o Relatório de Segurança de Pagamentos 2024 da Verizon, o percentual de organizações que mantêm conformidade total caiu consistentemente, chegando a 33% em 2023.
Trabalhamos com diversos líderes de segurança em eCommerce, Varejo e FinTech para implementar soluções em conformidade com o PCI em páginas que lidam com dados sensíveis de usuários (como cartões de pagamento). Depois de observar os erros mais comuns e as melhores práticas, compilamos um guia com nossos aprendizados para facilitar o seu processo de conformidade.
"Os passos técnicos para alcançar o PCI 6.4.3 & 11.6.1 é algo que me pedem regularmente para explicar às equipes de conformidade. Os documentos são claros sobre o que é exigido, mas como implementar os mecanismos continua sendo uma área cinzenta que as equipes de segurança precisam descobrir por conta própria".
— Simon Wijckmans, Fundador, cside
O que são os Requisitos do PCI DSS 6.4.3?
Como parte das adições do PCI DSS 4.0.1 que se tornaram obrigatórias em 31 de março de 2025, o requisito 6.4.3 exige que as empresas:
- Mantenham um inventário de todos os scripts em execução nas páginas de pagamento.
- Documentem por que cada script é necessário (justificativa de negócio).
- Verifiquem a integridade de cada script (garantindo que não foi alterado).
- Detectem e alertem sobre alterações não autorizadas em scripts.
O que isso significa em linguagem simples: Nas páginas que lidam com informações sensíveis do usuário (cartões de pagamento, informações de saúde, PII), você precisa ter um mecanismo para monitorar scripts de terceiros, o que eles estão fazendo nos navegadores dos seus usuários, e alertar as equipes de segurança quando os scripts estiverem se comportando de forma suspeita.
Definições baseadas no PCI DSS v4.0.1 - Jun. 2024. Esta é a versão mais atualizada em setembro de 2025. Para visualizar os documentos oficiais, acesse a biblioteca do PCI SSC.
O que são os Requisitos do PCI DSS 11.6.1?
Como parte das adições do PCI DSS 4.0.1 que se tornaram obrigatórias em 31 de março de 2025, o requisito 11.6.1 exige que as empresas:
- Alertem o pessoal sobre alterações não autorizadas nos cabeçalhos HTTP e nos scripts das páginas de pagamento
- Avaliem os cabeçalhos HTTP recebidos e as páginas de pagamento
- Operem pelo menos semanalmente ou conforme a análise de risco da entidade (Requisito 12.3.1)
O que isso significa em linguagem simples: Os cabeçalhos HTTP são regras que dizem ao navegador do usuário como lidar com o conteúdo de uma página. Alterar esses cabeçalhos (por exemplo, por um script malicioso) pode enfraquecer as proteções de segurança. O PCI DSS 11.6.1 exige que as empresas tenham um mecanismo que verifique regularmente (pelo menos uma vez a cada sete dias) se há alterações não autorizadas nos cabeçalhos e alerte a equipe de segurança quando elas ocorrerem.
Métodos para alcançar a conformidade com 6.4.3 e 11.6.1 (Comprar ou Fazer Internamente):
- Construir uma solução interna: Criar ferramentas internas para rastrear páginas de pagamento, registrar scripts, analisar payloads de scripts e alertar sobre alterações. Essa abordagem requer tempo contínuo de engenharia de pessoal especializado.
- Usar uma ferramenta pronta: Uma plataforma de inteligência no lado do cliente manterá automaticamente um inventário de scripts atualizado, fornecerá justificativas e enviará alertas sobre alterações não autorizadas. Os recursos de relatório geralmente são desenvolvidos especificamente para auditorias do PCI DSS.
"Quanto à questão de construir internamente ou comprar uma ferramenta: é uma decisão individual para cada empresa. Mas ainda não tive um cliente que tenha feito isso corretamente internamente. Em toda a nossa empresa, vi apenas um cliente que conseguiu fazer isso internamente com sucesso. E isso depois de trabalhar com centenas de clientes. Uma ferramenta de fornecedor realmente elimina as suposições."
- Marc Jackson, QSA & Consultor de Conformidade, MegaplanIT
Detalhamento do PCI DSS 6.4.3 e Passos para Conformidade
Quem é responsável pela conformidade com 6.4.3 e 11.6.1:
- Desenvolvedores controlam quais scripts são implantados e mantêm o inventário atualizado.
- Equipes de segurança monitoram alterações suspeitas e investigam alertas.
- Equipes de conformidade garantem que a documentação, as aprovações e as trilhas de auditoria atendam aos padrões do PCI.
Como são os relatórios aprovados por QSA para 6.4.3 e 11.6.1:
Algumas ferramentas de baixo custo ou gratuitas exportam dashboards confusos ou arquivos CSV. Esses são difíceis de interpretar para os auditores e ainda mais difíceis de operacionalizar para as equipes internas. Na prática, os QSAs buscam relatórios estruturados e revisáveis que mostrem o inventário de scripts, o status de autorização e a detecção de alterações ao longo do tempo. Relatórios bem organizados também facilitam que sua equipe aja rapidamente diante de comportamentos suspeitos.
Este vídeo apresenta os relatórios que usamos tanto como empresa auditada de forma independente com SAQ-D quanto como fornecedor com controles validados pela VikingCloud.
<a
class="pci-video-card__cta"
href="https://cside.com/landing/pci-demo-video"
target="_blank"
rel="noopener noreferrer"
>
<span class="pci-video-card__icon" aria-hidden="true">
<svg viewBox="0 0 48 48" fill="none" xmlns="http://www.w3.org/2000/svg">
<circle cx="24" cy="24" r="20.5" stroke="currentColor" stroke-width="2"/>
<path d="M20 16.5L31 24L20 31.5V16.5Z" stroke="currentColor" stroke-width="2" stroke-linejoin="round"/>
</svg>
</span>
<span>Assistir ao Vídeo</span>
</a>
O que os auditores buscam na conformidade com o PCI 6.4.3
1. Manter um inventário de todos os scripts em execução nas páginas de pagamento
"Uso tantos scripts de terceiros, ferramentas de análise, widgets de suporte, polyfills, bibliotecas de animação, CDNs. Qualquer um desses poderia se tornar malicioso e substituir o conteúdo legítimo por um keylogger ou algo pior." - Edgardo C., Desenvolvedor (Citação retirada de uma avaliação do cside)
A maioria dos sites tem entre 5 e mais de 100 scripts. Uma plataforma de inteligência no lado do cliente mantém um inventário em todas as páginas (incluindo páginas de pagamento no seu domínio) e mostra o payload do script em cada requisição. Isso permite que você veja alterações de código, atualizações e ações potencialmente maliciosas. Tudo isso é organizado de forma clara em um dashboard para que as partes interessadas tenham visibilidade. Embora não seja exigido pelo PCI DSS 4.0.1, algumas plataformas também bloqueiam e alertam sobre alterações (maliciosas).
2. Documentar por que cada script é necessário com uma justificativa de negócio (PCI 6.4.3)
Atender a esse requisito manualmente geralmente segue este processo:
-
- Exportar uma lista de scripts de um web crawler ou ferramenta de navegador, 2. Identificar o responsável por cada script (interno, fornecedor), 3. Registrar tudo em um documento central (por exemplo, planilha), 4. Adicionar um campo de texto com a justificativa de por que o script é necessário, 5. Atualizar o documento sempre que scripts forem adicionados, removidos ou modificados.
Uma plataforma de inteligência no lado do cliente:
- Armazena cada justificativa diretamente ao lado do script no seu inventário, garantindo que o contexto esteja sempre atualizado em um local central.
- Gera justificativas com IA para cada script, oferecendo às equipes um ponto de partida pré-escrito que podem revisar, aprovar ou ajustar.
3. Verificar a integridade de cada script para garantir que não foi alterado (PCI 6.4.3)
Agentes maliciosos podem modificar scripts para que se comportem de maneiras para as quais não foram originalmente projetados. Por exemplo:
- Modificar formulários de pagamento para enviar dados a um servidor controlado pelo invasor (exfiltração de dados)
- Adicionar campos de entrada ocultos ou keyloggers para capturar credenciais do titular do cartão
É por isso que soluções multicamadas que analisam o JavaScript durante cada sessão ao vivo são essenciais. Elas veem cada script exatamente como é executado no navegador do usuário, facilitando para os engenheiros entenderem o que o script está fazendo. A IA também filtra as alterações e fornece informações sobre o que a funcionalidade adicionada ou modificada pode fazer.
4. Detectar e alertar sobre alterações não autorizadas em scripts (PCI 6.4.3)
Você precisa mostrar aos auditores como os scripts mudaram ao longo do tempo. Uma técnica de ataque popular é fazer pequenas modificações em scripts existentes. Essas modificações frequentemente passam despercebidas porque as equipes de segurança não conseguem (e realisticamente não podem) revisar manualmente as alterações de código de cada script de forma contínua. Uma ferramenta de monitoramento automatizado rastreará essas alterações e registrará timestamps para fornecer um histórico claro para consulta.
Detalhamento do PCI DSS 11.6.1 e Passos para Conformidade
O requisito 11.6.1 é um pouco mais técnico. Ele estabelece que o pessoal precisa ser alertado quando os cabeçalhos HTTP e os scripts nas páginas de pagamento forem alterados. Isso é praticamente impossível de fazer manualmente. O JavaScript de terceiros não foi projetado para ficar estático. Ele é atualizado com base na localização do usuário, no tipo de navegador e na hora do dia. Alguns scripts precisam servir versões diferentes por razões funcionais. Então, como você pode ver, muito menos entender, essas mudanças?
O que os auditores buscam na conformidade com o PCI 11.6.1
1. Alertar o pessoal sobre alterações não autorizadas nos cabeçalhos HTTP e nos scripts das páginas de pagamento (PCI 11.6.1)
Os cabeçalhos HTTP são regras que dizem ao navegador do usuário como lidar com o conteúdo de uma página. Se forem alterados, isso representa um risco de segurança. Uma solução de segurança web no lado do cliente monitora os dados dos scripts para identificar diferenças de comportamento entre sessões separadas.
2. Avaliar os cabeçalhos HTTP recebidos e as páginas de pagamento (PCI 11.6.1)
Avaliar os cabeçalhos HTTP significa monitorar coisas como políticas de segurança de conteúdo. Fazer isso manualmente, página por página, inevitavelmente levará a sinais perdidos. Uma ferramenta de segurança no lado do cliente faz isso automaticamente, de modo que cada cabeçalho é validado e o processo de avaliação exige menos esforço manual da sua equipe.
3. Operar pelo menos semanalmente ou conforme a análise de risco da entidade (PCI 11.6.1 e 12.3.1)
O PCI DSS oferece duas opções aqui. Execute suas verificações pelo menos uma vez por semana. Ou execute-as com mais frequência se sua própria análise de risco indicar que você deve. Quando feito manualmente, seria necessário que alguém carregasse a página de pagamento, obtivesse os cabeçalhos HTTP, os comparasse com a cópia da semana anterior e fizesse o mesmo para o conteúdo da página. Em seguida, documentasse tudo toda semana ou com mais frequência, se o seu perfil de risco exigir.
O cside registra os cabeçalhos toda vez que sua página é carregada, então você não fica preso fazendo comparações manuais. Os relatórios são enviados para sua caixa de entrada regularmente (por exemplo, semanalmente) e armazenados na plataforma. Isso cria uma trilha de papel completa para conformidade.
Por que a Conformidade com o PCI é Importante (Exemplos de Ataques e Multas)
O PCI DSS existe para proteger os usuários da internet contra o roubo de informações de pagamento. Mais de 72.000 sites foram comprometidos apenas no segundo trimestre de 2025. Se hackers conseguirem acesso para editar código que carrega em um navegador, eles podem roubar muito mais do que informações de cartão de crédito. Eles roubam identidades. Esvaziam contas bancárias. Deixam as pessoas lidando com uma bagunça que pode levar meses para resolver. Seguir as regras do PCI ajuda a evitar multas que variam de US$ 5.000 a US$ 100.000. Também protege você contra vazamentos de dados no lado do cliente que custam às empresas mais de US$ 20 milhões, além da perda de confiança valiosa dos consumidores.
Comparação de Ferramentas para PCI 6.4.3 e 11.6.1
Muitas soluções de PCI visam marcar a caixa de conformidade sem oferecer proteção real aos seus usuários. Outras soluções usam tecnologia desatualizada, deixando os clientes surpresos quando não passam nas auditorias do PCI após uma implementação de vários meses. Certifique-se de que a solução do seu fornecedor foi revisada e aprovada por um QSA (Qualified Security Assessor) credenciado.
Diferentes Abordagens Técnicas para PCI 6.4.3 e 11.6.1
O detalhamento a seguir é extraído da Comparação de Tecnologias de Segurança no Lado do Cliente:
Abordagens baseadas em Crawler escaneiam a página após o fato, e frequentemente apenas de forma periódica. Elas falham em imitar o comportamento real do usuário, e os invasores podem facilmente escapar da detecção servindo scripts limpos para os crawlers enquanto direcionam payloads maliciosos aos usuários reais.
Content Security Policies (CSPs) têm escopo limitado. Elas tratam da origem do script, e não do seu payload. Quando a origem é comprometida, isso passa despercebido. Quando um script dinâmico é usado, uma Content Security Policy não tem como saber o que esse script está realmente servindo.
Detecção por JS no lado do cliente (também chamada de Agentes) injeta scripts de monitoramento nos navegadores. Eles configuram armadilhas para tentar detectar JavaScript malicioso. Porém, essas armadilhas geralmente são facilmente encontradas e, consequentemente, evitadas.
O cside aborda todos os problemas mencionados acima usando uma solução multicamadas que inclui agentes JS, scanners, CSPs, feeds de ameaças e muito mais. A plataforma cside também busca scripts em seus próprios servidores de forma assíncrona para inspeção abrangente sem introduzir atrito nos fluxos dos usuários.
Ferramentas Populares para PCI 6.4.3 e 11.6.1
| Nome | Abordagem | Avaliações | Saiba Mais |
|---|---|---|---|
| cside | Abordagem multicamadas com JavaScript Agent | ★★★★★ (4,9 estrelas) no G2 | Avaliação da Solução Cside |
| Feroot | Detecção Baseada em JavaScript | ★★★★★ (4,8 estrelas) no G2 | Avaliação da Solução Feroot |
| Imperva | Content Security Policy (CSP) | ★★★★☆ (4,5 estrelas) no G2 | Avaliação da Solução Imperva |
| DataDome | JavaScript Agent | ★★★★★ (4,8 estrelas) no G2 | Avaliação da Solução DataDome |
| JScrambler | JavaScript Agent | ★★★★☆ (4,3 estrelas) no G2 | Avaliação da Solução JScrambler |
"As capacidades de detecção que obtivemos com o Cside foram diferentes de tudo que vimos em outros produtos que testamos no passado. Definitivamente recomendaríamos o produto para PCI e muito mais." - Mark D., (Citação da Avaliação no G2 do cside)
Sub Resource Integrity (SRI) para Conformidade com o PCI DSS
No documento PCI DSS v4.0.1, o PCI SSC lista o SRI (sub-resource integrity) como um mecanismo válido para verificar a integridade dos scripts e atender ao requisito 6.4.3. Você pode ler mais sobre Sub Resource Integrity aqui para entender como funciona.
Por que o SRI Sozinho Falha no PCI DSS 6.4.3 na Prática
O Sub Resource Integrity funciona bem para scripts estáticos, mas falha ao lidar com scripts dinâmicos. Muitos scripts web de terceiros são dinâmicos e frequentemente atualizados. Cada alteração legítima exige novo hashing e reimplantação, o que rapidamente se torna inviável. Se o seu site tem uma equipe de marketing, você provavelmente tem scripts dinâmicos — pense em tags de analytics, ferramentas de teste A/B ou pixels de rastreamento.
Portanto, o SRI não é um método viável de conformidade com o PCI DSS ou de segurança para um ambiente web com scripts dinâmicos.
Combinar o SRI com uma diretiva CSP (script-src) fortalece a proteção, mas essa abordagem também falha quando os scripts são atualizados com frequência. Qualquer alteração legítima no conteúdo invalida o hash, fazendo com que o script pare de carregar e possivelmente quebre funcionalidades no seu site.
Alternativa ao SRI para verificar a integridade dos scripts:
Em vez de depender da manutenção manual de CSP e SRI para conformidade com o PCI DSS, você pode implantar uma ferramenta de monitoramento de integridade de scripts. Soluções modernas como o cside escaneiam continuamente em busca de modificações suspeitas e alertam sobre alterações com base em uma variedade de pontos de dados:
- Análise contínua por IA: Avalia como os scripts se comportam no navegador para sinalizar anomalias ou código injetado
- Comparação histórica de hashes: Rastreia alterações entre versões anteriores de scripts para análise forense precisa de adulterações ou atualizações
- Inteligência de ameaças: Faz referência cruzada de scripts com exposições conhecidas na cadeia de fornecimento web que afetam scripts no seu site.
Obtenha Ajuda da Nossa Equipe
Precisa de clareza sobre o PCI 6.4.3 ou 11.6.1? Nossa equipe pode avaliar pontos cegos na sua infraestrutura atual e mostrar como o cside facilita a conformidade.
O cside oferece tudo o que você precisa para passar no PCI 6.4.3 e 11.6.1.
✓ Faça o inventário automático de todos os scripts nas suas páginas de pagamento e acompanhe as alterações em tempo real.
✓ Armazene justificativas e economize horas de trabalho com justificativas geradas por IA para você aprovar ou editar.
✓ Monitore cabeçalhos HTTP e detecte modificações não autorizadas, alertando sua equipe instantaneamente.
Checklist Resumido para PCI DSS 6.4.3 e 11.6.1
Para o 6.4.3 e o 11.6.1, este é o checklist resumido que percorremos na nossa primeira conversa com as equipes de segurança:
| ◯ | Você tem um mecanismo capaz de detectar scripts maliciosos? |
| ◯ | Você tem um mecanismo que bloqueia scripts maliciosos (e consegue demonstrar que ele realmente verificou o código)? |
| ◯ | Você mantém uma lista dos scripts com justificativas de negócio e técnicas? |
| ◯ | Você monitora os cabeçalhos HTTP em uma página web? |
| ◯ | Você entende as diferentes abordagens técnicas para segurança no lado do cliente? (CSP, JS Agent, Proxy)? |
| ◯ | Você planeja atender aos novos requisitos com uma solução desenvolvida internamente ou com ferramentas prontas? |
Perguntas Frequentes sobre PCI DSS 6.4.3 e 11.6.1
Você está isento de cumprir o PCI 6.4.3 e 11.6.1? (Autoavaliação para SAQ A)
A atualização de janeiro de 2025 do PCI DSS para o SAQ A introduziu possíveis isenções dos requisitos 6.4.3 e 11.6.1, mas os critérios são descritos em termos vagos e de alto nível. Na prática, você precisaria provar que suas páginas de pagamento não contêm scripts de terceiros nem outros conteúdos dinâmicos. Esse cenário é raro para a maioria dos comerciantes. Obter a isenção é extremamente difícil. Para uma análise detalhada dos critérios e um fluxo lógico visual que você pode usar para avaliar sua própria situação, acesse nosso artigo dedicado "O que é um SAQ A e como aplicar".
Como Cumprir o PCI DSS 6.4.3 Gratuitamente
Não existem ferramentas de fornecedores que tornem você totalmente em conformidade com o PCI de graça. Algumas oferecem um período de teste gratuito ou um nível gratuito limitado, mas com qualquer volume significativo de tráfego web você acabará pagando custos baseados em uso. A outra opção é construir uma solução internamente. Mesmo que você tenha o talento de engenharia disponível, isso acaba custando muito mais do que comprar uma solução pronta. Se você quiser o detalhamento técnico do que envolve o caminho DIY, veja nosso artigo: Alcançando a Conformidade PCI Sem Comprar uma Solução.
