Conformidade PCI DSS gratuita vs paga: o que realmente funciona

PCI DSS 6.4.3 e 11.6.1 são preocupações do lado do cliente, e a maioria das organizações nunca precisou lidar com elas nesse nível de escrutínio antes.

Sem tempo? Conheça a plataforma de conformidade PCI DSS client-side da cside. Cobre tudo o que segue em uma única implantação.

Então, é possível alcançar a conformidade PCI com ambos os requisitos sem uma solução paga? A resposta é: Não, mais ou menos. Mas você gastaria muito mais dinheiro em salários do que pagaria por uma solução.

Essa frase importante deve estar na sua cabeça enquanto você lê este artigo. Ela foi adicionada na atualização de janeiro referente aos requisitos 6.4.3 e 11.6.1.

"Para que os comerciantes se qualifiquem para o SAQ A, eles devem confirmar que seu site não é suscetível a ataques de scripts que possam afetar o(s) sistema(s) de e-commerce do comerciante".

Por que esses requisitos foram estabelecidos

Desde que o JavaScript foi adicionado aos navegadores em 2011, a execução no lado do cliente abriu caminho para ataques generalizados de roubo de dados de cartão. Atores sofisticados agora injetam scripts maliciosos por meio de dependências, plugins ou comprometimentos na cadeia de suprimentos, ameaçando a segurança dos dados de cartões de pagamento. Na maioria das vezes, eles exfiltram dados de pagamento de forma dinâmica, frequentemente mirando apenas uma pequena porcentagem de usuários para passar despercebidos.

Visa, Mastercard e Amex apontaram ataques baseados em scripts do lado do cliente como a principal fonte de roubo de dados de cartão de crédito. A tokenização ajuda, mas apenas até certo ponto. Se o cliente for comprometido, o ataque ainda terá sucesso.

Por isso, o PCI DSS v4.0 exige, com razão, que as empresas implementem controles para:

• Impedir a execução de scripts não autorizados (6.4.3)
• Garantir a integridade dos scripts (6.4.3)
• Manter um inventário atualizado de scripts com justificativas de negócio (6.4.3)
• Detectar adulterações ou modificações não autorizadas nas páginas de pagamento (11.6.1)

Como alcançar a conformidade PCI DSS sem comprar uma solução

Se você tem recursos, capacidade técnica e disposição para manter as ferramentas por conta própria, veja como é possível fazer isso.

1. Impedir Scripts Não Autorizados (6.4.3)

Para atender ao requisito de garantir que apenas scripts autorizados possam carregar e executar, você precisa de uma camada de controle robusta. Uma Content Security Policy (CSP) pode cumprir esse papel, mas precisa ser configurada de forma rigorosa e mantida ativamente.

O que você pode fazer:

• Implante um cabeçalho CSP restrito usando script-src para criar uma lista de domínios permitidos.
• Use nonces ou hashes para permitir explicitamente scripts inline ou dinâmicos.
• Audite sua política regularmente e atualize-a a cada alteração de script.

É suficiente para o PCI? Sim, MAS apenas em termos formais. Scripts dinâmicos NÃO podem ser totalmente protegidos com CSP.

O CSP é reconhecido como um controle válido para autorizar scripts. No entanto, o CSP sozinho não rastreia a intenção. Você precisa de documentação de suporte que comprove por que cada fonte permitida foi autorizada.

MAS, lembre-se da frase acima:

"Para que os comerciantes se qualifiquem para o SAQ A, eles devem confirmar que seu site não é suscetível a ataques de scripts que possam afetar o(s) sistema(s) de e-commerce do comerciante".

O CSP resolve isso nesse contexto? NÃO. Se uma fonte permanecer a mesma, mas o conteúdo do script entregue mudar, um CSP NÃO detectaria isso.

O ataque ao Polyfill em 2024 NÃO seria bloqueado por um CSP. Tecnicamente, isso significa que seu site É suscetível a ataques, portanto você precisa de uma ferramenta de segurança para estar em total conformidade. Você pode se cadastrar ou agendar uma demonstração para conversar com a gente.

Considere os pontos a seguir como parte do seu checklist de conformidade PCI:

• Use CSP com restrições script-src e nonces/hashes.
• O CSP deve ser atualizado e auditado regularmente.
• Gerencie o CSP com cuidado; ele é frágil e pode quebrar aplicações.

2. Verificar a Integridade dos Scripts (6.4.3)

Espera-se que você detecte quando um script foi adulterado. Para scripts estáticos, o Subresource Integrity (SRI) é uma solução padrão. Ele verifica se apenas scripts com o hash esperado carregam com sucesso.

O que você pode fazer:

• Adicione os atributos integrity e crossorigin a cada tag `` de terceiros.
• Busque os scripts periodicamente, calcule o hash e compare com os hashes conhecidos como corretos.

É suficiente para o PCI? Sim, MAS apenas para scripts estáticos. Scripts dinâmicos NÃO podem ser cobertos apenas com SRI.

Scripts dinâmicos (por exemplo, ferramentas de analytics, executores de testes A/B) frequentemente mudam a cada requisição e vão quebrar o SRI. O PCI espera que você reconheça e mitigue essa limitação, seja evitando scripts dinâmicos ou implementando uma forma de monitoramento.

Como monitorar esses scripts? Isso não é possível sem ferramentas. Seja uma solução paga (como a nossa aqui na cside 👋), ou uma solução construída por você mesmo.

Sem entrar em detalhes, veja como você poderia construir sua própria ferramenta de monitoramento:

1. Crie uma lista de URLs de scripts dinâmicos
2. Busque o conteúdo dos scripts
3. Normalize o payload, remova timestamps, cache-busters ou cabeçalhos de rastreamento de CDN (se necessário).
4. Salve uma versão limpa do conteúdo para comparação.

Calcule o hash ou faça diff do resultado

1. Se houver mudança: registre e emita um alerta.

Alerte sobre mudanças inesperadas

1. Envie um e-mail, por exemplo.

Documente seu processo

1. O PCI quer evidências de que você está monitorando ativamente a integridade dos scripts.
2. Mantenha logs dessas verificações e de quaisquer ações resultantes.

Mas isso é praticamente viável?

Você construiria seu próprio software antivírus, por exemplo? Diríamos que, para a maioria de nós, a resposta é um claro "não". Construir um mecanismo para identificar comportamentos maliciosos em JS é algo difícil e exigirá um conjunto de dados substancial para ter sucesso. Isso vai além de uma questão de custo de tempo. É também uma questão de recursos.

Resumo:

• SRI funciona apenas para scripts estáticos. Use onde for possível.
• SRI NÃO funciona com scripts que têm payloads variáveis.
• O monitoramento do conteúdo real dos scripts é necessário por meio de ferramentas.

3. Manter um Inventário de Scripts (6.4.3)

Espera-se que você mantenha um inventário de todos os scripts que são executados na página de pagamento. Isso inclui scripts estáticos e dinâmicos, bem como scripts inline, fontes de terceiros (como gerenciadores de tags ou analytics) e qualquer coisa carregada por frameworks (como React ou Vue). O PCI quer ver que cada script foi revisado, aprovado e tem uma justificativa de negócio ou técnica. Isso a cada 7 dias (base semanal).

O que você pode fazer:

• Crie uma lista com controle de versão (planilha ou arquivo YAML/JSON).
• Inclua: fonte do script, hash esperado (se estático), justificativa de negócio/técnica, responsável/equipe.
• Atualize a cada implantação ou alteração de código (não alterações no código do script) que afete a página de pagamento.

Veja o que você precisa incluir:

• A fonte ou URL
• Se é estático ou dinâmico
• Um hash (se estático e SRI for utilizado)
• Justificativa de negócio/técnica
• Responsável ou equipe responsável
• Observações sobre monitoramento (especialmente para scripts dinâmicos)

Guias relacionados

Aprofunde-se no cluster:

• as responsabilidades PCI DSS compartilhadas da Stripe
• as responsabilidades PCI DSS compartilhadas da Adyen
• as responsabilidades PCI DSS compartilhadas do PayPal Braintree
• comparativo de soluções para PCI DSS 6.4.3 e 11.6.1
• vikingcloud-approves-c-sides-security-platform-for-pci-dss-v4-0-1-requirement-6-4-3-and-11-6-1
• como cumprir com o PCI DSS 6.4.3
• as atualizações de janeiro de 2025 do PCI DSS SAQ A, explicadas

É suficiente para o PCI? Sim, o PCI não exige mais nada aqui. Uma lista manual é aceitável, desde que seja precisa e mantida. Scripts dinâmicos ainda precisam ser listados, mesmo que você não possa calcular o hash deles. Nesses casos, o PCI espera que você explique por que o SRI não pode ser usado e como o script está sendo monitorado. ATENÇÃO: Isso NÃO significa que você pode simplesmente criar um inventário e não agir sobre os pontos acima. É um requisito descrito de forma um pouco mais aberta, que alguns veem como a solução definitiva. Não é.

4. Detecção de Adulteração e Alterações (11.6.1)

O PCI quer que você detecte alterações não autorizadas na página de pagamento conforme recebida no navegador do usuário. Isso inclui alterações no conteúdo e nos cabeçalhos HTTP (como CSP, CORS, etc.).

O que você pode fazer:

• Use um navegador headless (por exemplo, Puppeteer) ou curl para buscar a página de pagamento ao vivo. Você precisará gastar dinheiro com isso...
• Capture cabeçalhos e conteúdo HTML.
• Compare com uma linha de base conhecida como correta e emita alertas sobre alterações.
• Normalize a saída se necessário para evitar falsos positivos (especialmente importante para conteúdo dinâmico).
• Documente quais alterações disparam alertas, quem responde e como.

É suficiente para o PCI? Sim, DESDE QUE você execute regularmente e tenha documentado quais alterações disparam alertas, quem é notificado e qual é o seu plano de resposta. A frequência exigida é semanal, A MENOS QUE seja justificada de outra forma por uma análise de risco.

Observação sobre páginas dinâmicas: Frameworks renderizados no cliente (React, Vue, etc.) frequentemente carregam ou modificam o DOM após o carregamento da página. Se você não levar isso em conta, seu monitoramento vai gerar falsos positivos. Para o PCI, isso é, em tese, aceitável, DESDE QUE você defina claramente o que de fato verifica (por exemplo, cabeçalho CSP, domínios de scripts externos, seletores DOM principais) e por quê. Caso você ainda sofra um ataque, lembre-se da frase importante: "Para que os comerciantes se qualifiquem para o SAQ A, eles devem confirmar que seu site não é suscetível a ataques de scripts que possam afetar o(s) sistema(s) de e-commerce do comerciante".

Resumo:

• Use curl ou navegador headless para capturar e comparar cabeçalhos e HTML.
• Normalize o conteúdo dinâmico para reduzir falsos positivos.
• Execute verificações semanalmente (ou com mais frequência com base no risco).
• Configure alertas e um processo de resposta documentado.

O que uma auditoria de conformidade PCI DSS 4.0.1 verifica para 6.4.3 e 11.6.1

Uma auditoria de conformidade PCI DSS 4.0.1 para lojistas de e-commerce examina se o inventário de scripts da página de pagamento está completo, se cada script possui uma justificativa de negócio ou técnica autorizada, e se o lojista consegue provar que um mecanismo de detecção de mudanças roda contra os cabeçalhos HTTP da página de pagamento pelo menos a cada sete dias. Os requisitos 6.4.3 e 11.6.1 são as duas cláusulas em que um QSA passará mais tempo para fluxos card-not-present.

Os artefatos visíveis na auditoria são específicos: uma lista de inventário de scripts com proprietário, propósito e hash esperado por entrada; aprovações documentadas; e evidência de logs de que o mecanismo de detecção de mudanças rodou na cadência requerida com alertas fluindo para um canal monitorado. Se qualquer desses artefatos estiver ausente ou não puder ser reproduzido sob demanda, a auditoria marcará 6.4.3 ou 11.6.1 como não conformes independentemente da qualidade de qualquer outro controle.

A cside produz o inventário de scripts automaticamente a partir de dados ao vivo da página de pagamento, mantém hashes e status de aprovação, e roda o loop de detecção de mudanças de 6.4.3 continuamente com uma trilha de evidência que um QSA pode extrair diretamente.

Os benefícios de negócio da conformidade PCI DSS além de evitar multas

Os benefícios da conformidade PCI DSS além de evitar multas são concretos: estabilidade da relação com o adquirente, confiança das bandeiras de pagamento e um custo materialmente menor de resposta a incidentes se uma violação acontecer. Lojistas continuamente conformes mantêm sua relação com o adquirente fora da fila de escalada, retêm acesso às faixas de interchange mais baixas oferecidas pelo seu processador e reduzem o volume de trabalho forense que um incidente dispara.

Há também um benefício downstream para grandes compradores de e-commerce. Times de compras enterprise cada vez mais exigem a atestação PCI DSS como pré-requisito de fornecedor. Conformidade contínua significa que o AoC está sempre atualizado quando uma solicitação de compras chega, em vez de uma corrida a cada ciclo anual.

O monitoramento contínuo da cside mantém a cadeia de evidência de 6.4.3 e 11.6.1 atualizada em tempo real, o que significa que a janela de preparação de auditoria encolhe de semanas de acerto para uma exportação no mesmo dia.

Não-conformidade com PCI DSS e as penalidades que os lojistas realmente enfrentam

A não-conformidade com PCI DSS carrega três níveis de penalidade que atingem os lojistas diretamente. As bandeiras de cartão aplicam multas via adquirente, tipicamente começando em alguns milhares de dólares por mês para uma primeira infração e escalando para valores mensais de cinco ou seis dígitos se o lojista permanecer não conforme ao longo de ciclos de auditoria. O adquirente frequentemente repassa essas multas integralmente e adiciona seu próprio acréscimo de serviço.

O segundo nível é o custo por transação. Um lojista considerado não conforme no momento de uma violação enfrenta taxas de interchange mais altas em transações subsequentes e maior responsabilidade por chargebacks. As penalidades por não-conformidade com PCI DSS se combinam com a responsabilidade decorrente da violação sob a legislação estadual e federal.

O terceiro nível é a penalidade estratégica. A não-conformidade persistente pode levar à perda dos direitos de processamento de cartões ou à inclusão no MATCH, o que restringe a capacidade do lojista de obter processamento de pagamento de outros adquirentes.

A cside reduz tanto o risco de não-conformidade quanto o custo de preparação de auditoria mantendo os controles 6.4.3 e 11.6.1 em um estado continuamente verificável.

Uma checklist concisa de conformidade PCI DSS 4.0.1 para 6.4.3 e 11.6.1

Uma checklist de conformidade PCI DSS 4.0.1 para os requisitos de página de pagamento 6.4.3 e 11.6.1 é curta, mas rigorosa. Percorra-a em ordem antes de uma auditoria:

1. Inventário completo de scripts. Cada script que carrega na página de pagamento está listado com origem, propósito, responsável de negócio e hash esperado quando o script é estático.
2. Aprovação documentada por script. Cada entrada possui uma decisão de aprovação registrada por uma pessoa responsável e um carimbo de tempo de revisão dentro do último ciclo.
3. Mecanismo de detecção de mudanças instalado. Uma ferramenta ou processo detecta alterações não autorizadas nos cabeçalhos HTTP e no conteúdo de scripts da página de pagamento e consegue produzir evidência de execuções.
4. Cadência semanal comprovada. A evidência de logs mostra que o mecanismo de detecção de mudanças rodou pelo menos a cada sete dias durante todo o período de auditoria.
5. Roteamento de alertas verificado. Os alertas chegam a um canal monitorado com um caminho de escalada para segurança ou engenharia.
6. Evidência de test-fire. Uma mudança de teste em uma página de pagamento fora de produção foi detectada e alertada dentro da janela requerida.
7. Controles compensatórios documentados, se utilizados. Qualquer desvio da abordagem padrão está documentado com a justificativa do controle compensatório.

A cside produz os itens 1 a 6 como evidência contínua, de modo que a auditoria se torna uma revisão do sistema em funcionamento em vez de uma reconstrução depois do fato.

Então, dá para fazer de graça?

Sim, mais ou menos. Mas é praticamente impossível.

É tecnicamente possível, mas praticamente E estruturalmente frágil. Mais importante ainda, você muito provavelmente gastará mais dinheiro, tempo e recursos do que optando por uma solução paga.

Você precisaria:

• Escrever suas próprias ferramentas ou scripts
• Construir seu próprio método para analisar scripts, isso é custoso e, como empresa não especializada em segurança, você provavelmente não teria acesso aos dados ou às competências necessárias para isso. Você construiria seu próprio antivírus?
• Monitorar a integridade dos scripts manualmente
• Manter um inventário de scripts com disciplina
• Normalizar e comparar páginas dinâmicas sem se afogar em falsos positivos

E o mais importante: Você precisa provar que seu site não é suscetível a ataques do lado do cliente, conforme exigido explicitamente na atualização do PCI DSS de janeiro.

Um CSP não vai impedir ataques à cadeia de suprimentos. Um SRI não é compatível com scripts dinâmicos. E uma verificação básica com curl não vai proteger contra exfiltração seletiva e sensível ao contexto.

Se você for pelo caminho do faça você mesmo: Documente tudo, automatize onde puder e prepare-se para a sobrecarga. E, se possível, construa suas próprias ferramentas. Mas, acima de tudo, calcule seu tempo e recursos (humanos ou não) e faça as contas. As chances são de que você estaria melhor servido optando por uma solução paga.

Se você quer estar em total conformidade e seguro, construímos o cside exatamente para isso. Você pode agendar uma demonstração aqui ou se cadastrar para estar em conformidade hoje mesmo.

Entendendo especificamente PCI 11.6.1

Enquanto 6.4.3 foca em inventário e justificativa de scripts, PCI DSS 11.6.1 foca em detectar alterações não autorizadas em scripts e cabeçalhos de segurança HTTP em páginas de pagamento.

PCI 11.6.1 exige que você:

• Monitore o conteúdo e a configuração de cada script executado em páginas de pagamento
• Detecte adulteração, injeção ou modificação não autorizada em tempo hábil
• Alerte a equipe apropriada quando alterações não autorizadas forem detectadas

A palavra "em tempo hábil" é intencionalmente deixada à interpretação do QSA, mas geralmente é lida como detecção em minutos a horas após a alteração. Verificações semanais ou mensais não satisfazem 11.6.1. O monitoramento contínuo da cside dispara alertas em tempo real à medida que as alterações ocorrem, dando à sua equipe de segurança a janela de resposta que a conformidade exige.