O PCI DSS 4.0 chegou. A partir de março de 2025, ele exige que os portais de pagamento tenham uma forma de autorizar cada script nas páginas de pagamento. Os sites precisam manter um inventário de todos os scripts (pelo menos nesses portais de pagamento) e garantir sua integridade. Agora é necessário detectar e responder a modificações não autorizadas nas páginas de pagamento, incluindo alterações em cabeçalhos HTTP e no conteúdo das páginas. As organizações devem verificar essas configurações pelo menos uma vez a cada sete dias ou conforme determinado por sua análise de risco.
Leia os requisitos completos aqui.
Outro ponto importante é que o PCI DSS 4.0 agora incentiva a migração de auditorias anuais para o monitoramento contínuo de segurança, com revisões e atualizações regulares dos componentes de sistema e softwares.
Finalmente!
Por enquanto, apenas os portais de pagamento são obrigados a ter um sistema para controlar o JavaScript de terceiros. É por isso que muitos dos nossos concorrentes (veja o que achamos deles aqui) limitam seus serviços a apenas algumas páginas. Alguns até fazem amostragem de sessão, protegendo apenas 10% das sessões.
Mas isso é pedir para ter problemas.
Por que você deve proteger todas as páginas
Ainda existe risco de violação de dados se você não proteger todas as páginas.
Agentes maliciosos podem usar scripts comprometidos em outras partes do seu site para sequestrar sessões de usuários. Isso poderia permitir que eles se passassem por usuários legítimos e realizassem ações não autorizadas, potencialmente até contornando algumas formas de autenticação de dois fatores. Isso poderia, em última instância, burlar a proteção de scripts de terceiros nos portais de pagamento.
Outra área que você deixaria exposta a riscos são as vulnerabilidades de Cross-site scripting (XSS). Elas permitem que invasores injetem scripts maliciosos em páginas web visualizadas por outros usuários. Se apenas o portal de pagamento estiver protegido, outras páginas podem ser exploradas para executar ataques XSS, afetando os dados e a privacidade dos usuários de qualquer forma.
Em alguns casos, os Ataques à Cadeia de Suprimentos também não são totalmente bloqueados. Scripts de terceiros são um vetor comum para esse tipo de ataque. Se invasores comprometerem um fornecedor ou um script utilizado em todo o seu site, concentrar as proteções apenas no portal de pagamento não impedirá a exploração por meio de outras integrações de terceiros.
Vulnerabilidades de Execução Remota de Código (RCE) e Injeção de Comandos representam riscos de segurança significativos que reforçam ainda mais a necessidade de proteger todas as páginas, não apenas áreas críticas como os portais de pagamento. O RCE permite que invasores executem código arbitrário no seu servidor, podendo levar ao comprometimento total do sistema. Isso pode ocorrer por meio do tratamento inadequado de entradas do usuário, como a avaliação de código enviado por usuários ou injetado por campos de formulário.
Vulnerabilidades de Injeção de Comandos surgem quando entradas de usuário não seguras são executadas como comandos do sistema, especialmente por meio de entradas JavaScript inadequadamente sanitizadas. Isso pode permitir que invasores manipulem ações do servidor ou acessem bancos de dados de back-end, resultando em alterações não autorizadas ou roubo de dados.
Por fim, engenharia social e phishing são ameaças reais. Invasores podem modificar conteúdo ou redirecionar usuários para sites maliciosos, induzindo-os a fornecer informações sensíveis.
Outras vulnerabilidades
Mesmo que seus portais de pagamento estejam protegidos e a proteção funcione, você ainda corre o risco de que scripts em outras páginas sejam comprometidos, como já estabelecemos.
Se isso acontecer, você ainda corre o risco de perder a confiança dos usuários e potencialmente enfrentar implicações legais ou regulatórias, especialmente em relação a leis de proteção de dados como o GDPR ou o CCPA. Os danos em multas decorrentes disso, ou os danos à reputação, são difíceis de quantificar. Mesmo assim, eles existem.
Então faça certo, desde já
Assim como as regras do PCI DSS 4.0, também incentivamos qualquer proprietário de site a adotar o monitoramento contínuo de segurança. E espero que tenhamos demonstrado que fazer isso em todas as páginas é a melhor abordagem.
O plano gratuito do cside deixa seu site em conformidade com o PCI DSS em relação a scripts de terceiros, e funciona em todas as páginas. Nossa abordagem é diferente da concorrência, no entanto. Nosso script reescreve as origens de outros scripts no seu site para proxy-los pelo cside e realiza algumas detecções no lado do navegador. Isso coloca o cside no fluxo da requisição entre o usuário e o script de terceiros, sem latência adicional e, em alguns casos, até melhorando o desempenho por meio do cache de scripts estáticos.
Isso permite visibilidade total dos scripts servidos, em 100% das sessões e em todas as páginas. Protegendo tanto você quanto seus usuários.
Se quiser saber mais sobre como nossa abordagem se diferencia, acesse aqui.
