O PCI SSC publicou um FAQ sobre elegibilidade para empresas SAQ A, referente a scripts nos seus sites, mencionando os requisitos 6.4.3 e 11.6.1 do PCI DSS 4.0.1.
Essa atualização gerou confusão entre avaliadores, nossos clientes e potenciais clientes.
O SAQ A é destinado a comerciantes que terceirizam completamente o processamento de pagamentos para provedores de serviços terceirizados validados pelo PCI DSS. Nenhum dado de titulares de cartão deve ser processado, armazenado ou transmitido pelos sistemas do comerciante.
Um equívoco comum é achar que usar um iframe ou redirecionamento é suficiente. Não é.
O requisito principal é que o comerciante não deve carregar scripts que interajam com a página de pagamento. Se scripts do domínio do comerciante ou de terceiros estiverem presentes, o SAQ A não se aplica.
O papel dos scripts na conformidade com o SAQ A
- O formulário de pagamento deve ser hospedado e controlado inteiramente por um provedor em conformidade com o PCI.
- O comerciante não pode carregar scripts que modifiquem, monitorem ou interajam com o formulário de pagamento de nenhuma forma.
- Os únicos scripts permitidos são os gerenciados diretamente pelo provedor de pagamento validado.
Se a sua página de checkout inclui JavaScript — seja para analytics, melhorias de interface ou ferramentas de terceiros em geral — você pode não se qualificar para o SAQ A. Mesmo que um script não acesse os campos de pagamento, ele ainda pode introduzir riscos, como:
- Ataques de form-jacking que capturam a entrada do usuário antes que ela chegue ao provedor de pagamento.
- Modificações não autorizadas no DOM que afetam o processo de pagamento.
- Ataques à cadeia de suprimentos que exploram scripts de terceiros.
Uma frase gera debate
O comerciante confirmou que seu site não é suscetível a ataques de scripts que possam afetar o(s) sistema(s) de e-commerce do comerciante.
Essa frase foi adicionada na atualização de janeiro referente às empresas SAQ A.
Embora o PCI DSS se aplique a pagamentos e páginas de pagamento, essa frase deixa claro que o site inteiro não deve ser suscetível a ataques de scripts. Isso faz sentido. Se, por exemplo, um link que leva a uma página de pagamento não estiver protegido ou monitorado, uma injeção maliciosa de JavaScript de terceiros pode redirecionar o link e ainda assim comprometer o usuário.
Como isso deve ser feito não está claro, o que gera confusão.
O PCI SSC orienta a consultar a versão mais recente da lista PCI DSS SAQ A para obter a lista completa de critérios de elegibilidade, mas ela não traz nenhuma informação especificamente vinculada à citação acima.
Na lista SAQ A, essa citação menciona diretamente scripts a serem monitorados e/ou protegidos:
No item 6.4.3 (página 7):
Todos os scripts da página de pagamento que são carregados e executados no navegador do consumidor são gerenciados da seguinte forma: Um método é implementado para confirmar que cada script está autorizado. Um método é implementado para garantir a integridade de cada script. Um inventário de todos os scripts é mantido com justificativa por escrito sobre por que cada um é necessário.
Nessa seção, mencionam-se apenas os scripts da página de pagamento. Porém, nas notas de aplicabilidade abaixo, consta:
Este requisito se aplica a todos os scripts carregados do ambiente da entidade e a scripts carregados de terceiros e quartos.
O "ambiente da entidade" borra as fronteiras e abre espaço para a interpretação de "seu site" como um todo, conforme usado na frase que originou este debate.
Como os sites carregam scripts dinamicamente, um script de qualquer página pode persistir até o checkout, potencialmente interferindo nos pagamentos. Scripts de terceiros, mesmo que não relacionados ou em páginas carregadas antes das páginas de pagamento, podem introduzir vulnerabilidades.
Em Single Page Apps (SPAs), os scripts persistem entre as visualizações, o que significa que um script carregado em qualquer página ainda pode estar ativo durante o checkout. Da mesma forma, em Progressive Web Apps (PWAs), os scripts são executados continuamente enquanto os usuários navegam, aumentando o risco de interações não intencionais com o fluxo de pagamento.
No item 11.6.1 (página 16), nas notas de aplicabilidade:
A intenção deste requisito não é que uma entidade instale software nos sistemas ou navegadores de seus consumidores, mas sim que a entidade utilize técnicas como as descritas em Exemplos na coluna de Orientação do PCI DSS (de Requisitos e Procedimentos de Teste do PCI DSS) para prevenir e detectar atividades inesperadas de scripts.
Esse caminho nos leva a esses exemplos, encontrados na lista SAQ A na página vi. Na seção "Não Aplicável", consta:
O requisito não se aplica ao ambiente do comerciante. (Veja "Orientação para Requisitos Não Aplicáveis" abaixo para exemplos.) Todas as respostas nesta coluna exigem uma explicação de suporte no Apêndice D deste SAQ.
Apenas um exemplo é encontrado em "Orientação para Requisitos Não Aplicáveis":
Os requisitos para proteger todas as mídias com dados de titulares de cartão (Requisitos 9.4.1 - 9.4.6) se aplicam somente se um comerciante armazena mídia física com dados de titulares de cartão; se a mídia física não for armazenada, o comerciante pode selecionar Não Aplicável para esses requisitos.
O "Apêndice D" refere-se apenas a uma área onde a empresa que solicita o status SAQ A, ou os avaliadores que avaliam essas empresas, podem registrar suas conclusões sobre o assunto.
Como estar em conformidade?
Além de todos os outros requisitos do SAQ A, as empresas precisam comprovar que seu site está protegido contra ataques baseados em scripts não autorizados. Como comprovam isso ainda é uma questão em aberto. Na cside, criamos uma ferramenta que faz exatamente isso e permite que as empresas atendam aos requisitos 6.4.3 e 11.6.1. Dependendo da configuração do site, no entanto, existem outras formas, desde que estejam em conformidade com os demais requisitos necessários para ser elegível ao SAQ A.
Você precisa estar em conformidade com 6.4.3 e 11.6.1?
Se você é elegível para o SAQ A, está tecnicamente isento dos requisitos 6.4.3 e 11.6.1.
No entanto, a elegibilidade para o SAQ A exige que você confirme que seu site inteiro não é suscetível a ataques baseados em scripts que possam comprometer seu sistema de e-commerce. Embora o PCI SSC não defina explicitamente como validar isso, significa que você deve garantir que:
- Nenhum script não autorizado esteja sendo executado no seu site.
- Seu processo de checkout esteja protegido contra manipulações (por exemplo, sequestro de redirecionamento).
- Você monitore e proteja todas as integrações de terceiros.
Se você não é elegível para o SAQ A, deve estar em conformidade com os requisitos 6.4.3 e 11.6.1, pois seu ambiente se enquadra em uma categoria de conformidade mais elevada, onde controles de segurança adicionais são exigidos.
E tudo isso se aplica ao site inteiro, conforme a frase — "O comerciante confirmou que seu site não é suscetível a ataques de scripts que possam afetar o(s) sistema(s) de e-commerce do comerciante." — estabelece.
Exemplos de não qualificação (SAQ A não permitido)
- Checkout desenvolvido sob medida com chamadas diretas de API a um processador (SAQ D obrigatório).
- Uma página de checkout que inclui scripts não protegidos que afetam os campos de pagamento.
- Uso de campos hospedados por terceiros, mas com modificações via JavaScript.
- Não confirmar que o site não é suscetível a ataques de scripts que possam afetar os sistemas de e-commerce do comerciante.
Conclusão
O SAQ A oferece um caminho simplificado de conformidade para comerciantes que podem terceirizar completamente o processamento de pagamentos, mas as últimas esclarecimentos destacam uma mudança importante: as responsabilidades de segurança não se encerram na página de pagamento.
Embora 6.4.3 e 11.6.1 não se apliquem a comerciantes SAQ A, garantir que o site inteiro esteja protegido contra ataques baseados em scripts é agora um requisito.
Isso significa que os comerciantes precisam adotar medidas de segurança proativas — não apenas para manter a conformidade, mas para prevenir ameaças que possam comprometer seu ecossistema de e-commerce. CSP, SRI e monitoramento de integridade de scripts tendem a se tornar expectativas básicas, e não salvaguardas opcionais.
Com a cside, você está automaticamente em conformidade com os requisitos 6.4.3 e 11.6.1.
Ajudamos comerciantes a detectar, monitorar e mitigar riscos baseados em scripts. Se você não tem certeza sobre sua conformidade, podemos ajudá-lo a atender aos requisitos e manter a segurança.
Entre em contato conosco para proteger seu ambiente client-side e manter a conformidade com o SAQ A com confiança.
