Desde 31 de março de 2025, controles que o PCI DSS 4.x tratava como requisitos futuros passaram a valer nas avaliações aplicáveis. No comércio eletrônico, isso colocou sob maior escrutínio uma superfície que muitas empresas ainda administram como detalhe técnico: scripts executados no navegador, páginas de pagamento, integrações e prestadores que podem afetar a segurança dos dados de cartão.
O antigo debate sobre “estar pronto para o PCI DSS 4.0” ficou para trás. Em 2026, a questão mais útil é outra: como transformar os requisitos do PCI DSS 4.0.1 em controles capazes de acompanhar uma cadeia de pagamentos cada vez mais dependente de terceiros, componentes externos e código executado fora do servidor da própria organização.
Essa mudança é especialmente relevante para e-commerce. Uma página pode manter seu código principal intacto e, ainda assim, expor clientes se um script carregado de um domínio externo, uma tag de marketing, um componente de analytics ou outra dependência autorizada for adulterada. O ataque não precisa “invadir o checkout” da forma tradicional; pode explorar justamente a confiança concedida a um recurso que já tinha permissão para executar no navegador.
O prazo acabou; o risco continua
Em março de 2025, o PCI Security Standards Council publicou orientação específica para segurança de páginas de pagamento e prevenção de e-skimming, com foco nos requisitos 6.4.3 e 11.6.1. O documento parte de um problema prático: páginas de comércio eletrônico ficaram mais complexas e passaram a depender de mais scripts externos, enquanto o navegador do consumidor se tornou um alvo relevante para roubo de dados de pagamento.
O Requisito 6.4.3 exige que os scripts presentes nas páginas de pagamento sejam administrados de forma controlada. Em termos operacionais, isso significa saber quais scripts estão autorizados, justificar sua necessidade e adotar mecanismos que permitam verificar sua integridade. O Requisito 11.6.1 complementa essa lógica ao exigir mecanismos de detecção de mudanças e adulterações que possam afetar a página de pagamento e os cabeçalhos HTTP relacionados à segurança.
A combinação muda a pergunta de segurança. Já não basta saber se o servidor web foi alterado. É preciso observar também o que efetivamente chega ao navegador, quais componentes são carregados naquele momento e se algo mudou sem autorização.
Onde terceiros entram na cadeia de pagamentos
A dependência de terceiros é inerente à operação digital. Processadores de pagamento, gateways, provedores de hospedagem, serviços de segurança, plataformas de comércio eletrônico e outros prestadores podem executar funções que fazem parte do ambiente de dados do portador do cartão ou que afetam sua segurança. O risco surge quando a organização conhece o contrato comercial, mas não conhece com a mesma precisão a fronteira técnica e a divisão de responsabilidades.
O Requisito 12.8 do PCI DSS trata justamente da gestão dessas relações com terceiros. A orientação do PCI SSC destaca a necessidade de realizar due diligence, manter acordos apropriados, identificar quais requisitos são responsabilidade da organização e quais são atendidos pelo prestador e acompanhar periodicamente o status de conformidade dos terceiros relevantes.
Isso não significa que qualquer fornecedor de JavaScript deva ser automaticamente classificado como um Third-Party Service Provider (TPSP). O próprio PCI SSC esclarece que um provedor cujo único serviço seja fornecer um script não relacionado ao processamento de pagamentos, e que não possa afetar a segurança dos dados do portador ou de autenticação, não é considerado TPSP apenas por esse fato. A avaliação precisa considerar o serviço prestado e sua capacidade real de impactar o ambiente.
Scripts no navegador: quando a cadeia de suprimentos chega ao checkout
O risco de e-skimming ajuda a explicar por que essa distinção importa. Código JavaScript executado na página pode enxergar campos, alterar o DOM, modificar fluxos e transmitir informações. Se um componente legítimo for comprometido em sua origem, um site que nunca sofreu invasão direta pode passar a entregar código malicioso aos próprios visitantes.
O caso Polyfill.io, em 2024, tornou esse cenário concreto. Após mudança de controle do domínio e do serviço, pesquisadores identificaram distribuição de JavaScript malicioso. A Cloudflare afirmou à época que dados de seu sistema de segurança no lado do cliente corroboravam relatos de injeção de código e recomendou a remoção do serviço. O episódio mostrou que uma dependência amplamente aceita pode mudar de risco sem que as aplicações que a consomem sofram qualquer alteração local.
Para uma organização sujeita ao PCI DSS, a lição vai além daquele incidente específico: confiança em fornecedor não pode ser confundida com integridade contínua do código entregue. Inventário e aprovação são importantes, mas precisam ser acompanhados por detecção de alteração e capacidade de reação.
Notícias Relacionadas
- Ataques de dentro para fora: quando a ameaça chega por uma dependência confiável
- Como a cibersegurança entra definitivamente na era da gestão de riscos
Terceirizar o pagamento não terceiriza a responsabilidade
Externalizar etapas de pagamento pode reduzir escopo técnico, mas não elimina automaticamente as obrigações da empresa. Quando um TPSP executa funções dentro ou relacionadas ao ambiente de dados do portador, a organização continua responsável por gerir a relação, entender a matriz de responsabilidades e verificar as evidências necessárias para sua própria avaliação.
Esse ponto é particularmente importante em arquiteturas com páginas de pagamento incorporadas por iframe. Em orientação de 2025 sobre elegibilidade ao SAQ A, o PCI SSC indicou que o comerciante pode demonstrar proteção contra ataques de scripts aplicando técnicas alinhadas aos requisitos 6.4.3 e 11.6.1 ou obtendo confirmação do processador/TPSP compatível de que a solução incorporada inclui proteções apropriadas quando implementada conforme as instruções do fornecedor.
Na prática, a segurança depende tanto da arquitetura adotada quanto da governança do relacionamento. Um contrato que diz “o fornecedor cuida do pagamento” não substitui uma matriz clara de responsabilidades, evidências de controles, processo de mudança e acompanhamento do status de conformidade.
O que uma organização deve fazer na prática
A resposta mais consistente combina gestão de terceiros, segurança de aplicações e monitoramento do lado do cliente. O ponto de partida é construir uma visão confiável de quais componentes podem afetar a página de pagamento e quem é responsável por cada um deles.
- Inventariar scripts e dependências: identificar código próprio e de terceiros carregado nas páginas de pagamento, sua origem, finalidade, responsável interno e justificativa de negócio.
- Reduzir o que não é necessário: remover tags, bibliotecas e integrações sem uso comprovado. Cada dependência eliminada reduz uma relação de confiança a ser monitorada.
- Controlar autorização e integridade: estabelecer processo para aprovar scripts e adotar mecanismos adequados para detectar alterações ou conteúdo inesperado.
- Monitorar a página como o cliente a recebe: controles apenas no servidor podem não identificar mudanças introduzidas por recursos externos durante a renderização no navegador.
- Mapear TPSPs e responsabilidades: manter contratos, evidências, due diligence, matriz de responsabilidades e acompanhamento periódico do status dos prestadores relevantes.
- Tratar mudanças de fornecedor como risco: aquisições, troca de domínio, alteração de infraestrutura, CDN ou mantenedores podem mudar a confiança de uma dependência sem modificar sua URL ou função aparente.
- Preparar resposta: definir quem pode retirar um script, bloquear uma origem, substituir um componente ou interromper uma integração quando houver suspeita de adulteração.
Conformidade precisa virar capacidade operacional
O principal risco de tratar o PCI DSS apenas como uma lista de evidências anuais é criar conformidade documental para uma superfície que muda todos os dias. Scripts são atualizados, fornecedores mudam infraestrutura, novas tags entram em produção e serviços externos passam a executar funções adicionais. A fotografia coletada durante uma avaliação perde valor rapidamente se a organização não consegue detectar essas mudanças.
Por isso, os requisitos relacionados a scripts, detecção de adulteração e terceiros devem conversar com processos já existentes de gestão de mudanças, AppSec, inventário de ativos, monitoramento, gestão de fornecedores e resposta a incidentes. A maturidade aparece quando a empresa consegue responder não apenas “quais controles declarou”, mas “o que mudou desde ontem e como saberia se uma dependência confiável começasse a entregar algo diferente”.
Conclusão
O PCI DSS 4.0.1 torna mais explícita uma realidade que os ataques à cadeia de suprimentos já demonstravam: parte relevante do risco de pagamento pode estar fora do código e da infraestrutura diretamente administrados pela empresa. Terceiros, scripts e componentes executados no navegador ampliam a cadeia de confiança — e, com ela, a necessidade de visibilidade, responsabilidade e monitoramento contínuo.
A melhor resposta não é bloquear indiscriminadamente serviços externos, mas saber quais são realmente necessários, que acesso possuem, como podem afetar os dados de pagamento, quem responde por seus controles e como uma alteração inesperada seria detectada. É nessa passagem da conformidade periódica para a gestão contínua que o PCI DSS se aproxima de uma prática efetiva de redução de risco.
Veja também
- Ataques de dentro para fora: quando a ameaça chega por uma dependência confiável
- Como a cibersegurança entra definitivamente na era da gestão de riscos
Be the first to comment