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.
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".
| Requisito | Dá para fazer de graça? | Observações |
|---|---|---|
| 6.4.3 – Impedir Scripts Não Autorizados | Sim, MAS | CSP funciona formalmente, mas não detecta conteúdo malicioso proveniente de fontes confiáveis. Não é suficiente para garantir que você "não é suscetível a ataques". |
| 6.4.3 – Verificar Integridade de Scripts | Não | SRI funciona apenas para scripts estáticos. Monitorar scripts dinâmicos exige construir suas próprias ferramentas. Você ficaria sem visibilidade sobre ameaças ativas. Basicamente, você acabaria construindo um antivírus. |
| 6.4.3 – Manter Inventário de Scripts | Sim | Uma lista manual (planilha ou configuração versionada) está em total conformidade, desde que seja mantida precisa e atualizada. |
| 11.6.1 – Detecção de Adulteração e Alterações | Não | Você pode detectar alterações em scripts, mas avaliar se foram adulterados ou se foi uma mudança legítima é muito difícil. |
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-srcpara 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-srce 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
integrityecrossorigina 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:
- Crie uma lista de URLs de scripts dinâmicos
- Busque o conteúdo dos scripts
- Normalize o payload — remova timestamps, cache-busters ou cabeçalhos de rastreamento de CDN (se necessário).
- Salve uma versão limpa do conteúdo para comparação.
- Se houver mudança: registre e emita um alerta.
- Envie um e-mail, por exemplo.
- O PCI quer evidências de que você está monitorando ativamente a integridade dos scripts.
- 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)
É 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.
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.
