O termo "integridade de scripts" aparece em requisitos de conformidade como PCI DSS 4.0.1, ISO 27001, HIPAA e outros frameworks — mas o que esse termo significa na prática e o que é esperado?
Por Que a Integridade de Scripts Importa para Merchants e Empresas de E-commerce
Ativos carregados de terceiros têm origem em fontes externas. Confiar incondicionalmente em uma fonte não é seguro no ambiente dinâmico da internet. Empresas SaaS surgem e desaparecem, e infelizmente muitas não têm um plano de contingência para os domínios que usavam nos ambientes de produção de seus clientes.
Ao longo dos anos, uma série de incidentes afetou consumidores desavisados ao redor do mundo.
Injeções por meio do sequestro de uma fonte de terceiros podem ocorrer de diversas formas.
- Engenharia social
- Sequestros direcionados a pipelines de CI/CD
- Dependências open source maliciosas
- Injeções de malware no nível da máquina nos dispositivos dos desenvolvedores
- Registro de domínios expirados
Não precisa ser um ataque sofisticado à cadeia de suprimentos — pode começar com um vetor de entrada bastante simples (como um domínio expirado) que abre uma brecha silenciosa para que atacantes manipulem o código em execução no seu site sem que ninguém perceba.
Na próxima vez que seus usuários inserirem informações nas suas páginas, dados sensíveis podem ser coletados por meio de iframes maliciosos sobrepostos a elementos de pagamento (web skimming), cadeias de redirecionamento forçadas, sequestro de cookies de afiliados, entrega de malware no nível do dispositivo ou até exploração de zero-days em navegadores.
Integridade de Scripts: Para Requisitos de Conformidade
Os frameworks de conformidade estão cada vez mais exigindo que as empresas monitorem a integridade e o histórico de alterações dos scripts client-side.
- Para PCI DSS 4.0.1: A validação de integridade de scripts é necessária para atender aos requisitos de detecção de mudanças em 6.4.3 e 11.6.1 (Como Cumprir o PCI DSS 6.4.3 e 11.6.1)
Integridade de Scripts: Para Prevenir Ataques Client-side
De acordo com a Mastercard, a principal fonte de skimming de cartões de crédito é o e-skimming, que ocorre no lado do cliente. Scripts comprometidos são uma porta aberta para que atacantes realizem:
- Formjacking, ataques Magecart, web skimming, redirecionamentos maliciosos para phishing e outros tipos de ataque que afetaram mais de 380.000 sites em 2025 (Relatório de Ataques Client-side 2025).
Gerenciamento de Integridade de Scripts: Para Empresas de E-commerce
Qualquer merchant que processa um alto volume de transações online é um alvo prioritário para exploração client-side.
- Sites modernos de e-commerce carregam dezenas de scripts de terceiros. Os merchants precisam de visibilidade sobre o que esses scripts estão fazendo, quando mudam e se essas mudanças estão alinhadas com o comportamento esperado.
O Que é Integridade de Scripts
Equívocos Sobre o Termo
O termo "integridade de scripts" provavelmente surgiu por priming lexical em relação ao método de gerenciamento "Subresource Integrity" referenciado nos principais frameworks de conformidade. Priming lexical é a reutilização de palavras que você encontrou recentemente — todos fazemos isso.
No entanto, usar a palavra "integridade" de forma isolada pode gerar confusão e está sujeito a interpretações diversas.
O Que Qualifica um Script como Tendo (ou Não) Integridade?
Monitoramento de Comportamento para Integridade de Scripts
Integridade, neste contexto, pode significar "garantir que os scripts não estejam se comportando de forma maliciosa". O problema é que a exfiltração de dados por si só não é um comportamento malicioso, assim como redirecionamentos também não são. Muitos scripts de terceiros fazem isso por razões legítimas, o que torna muito difícil fiscalizar mudanças.
Monitoramento de Alterações de Scripts para Integridade de Scripts
O fator de mudança é o que os frameworks de conformidade mais comumente abordam: garantir que, quando um script muda, essas alterações estejam alinhadas com o uso esperado do script.
O Que é Subresource Integrity (SRI)?
Subresource Integrity (SRI) é uma ferramenta de segurança nativa dos navegadores que permite ao proprietário de um site adicionar um hash a uma diretiva de script em uma aplicação web. O SRI existe desde 2015, quando Google e Mozilla o adotaram em seus navegadores, e foi posteriormente reconhecido pelo w3c em 2016.
Propósito do Subresource Integrity (SRI)
O objetivo do SRI era impedir que recursos estáticos carregados no client-side — como ativos com controle de versão — passassem a se comportar de forma dinâmica de repente. Exemplo: jQuery versão x.
Em sua essência, o SRI aborda o "fator de mudança" verificando se o conteúdo de um script permanece idêntico à sua versão conhecida e confiável.
Por Que o SRI Foi Adicionado ao CSP
Ao longo dos anos, cada vez mais funcionalidades do SRI foram incorporadas às Content Security Policies (CSP). O que levou à pergunta: por que ter os dois? Segurança é uma questão de camadas, então ter opções é positivo. No entanto, a limitação do CSP de não interagir ativamente com o conteúdo dos scripts levou ao próximo passo lógico: considerar a adição de hashes à especificação.
Por um tempo, o CSP confiava apenas em fontes, o que gerou o problema abaixo. Imagine que duas caixas chegam à sua porta. Ambas do mesmo remetente, mas uma contém um filhote de cachorro fofo e a outra uma bomba de glitter.
Me diga pelo endereço do remetente qual é qual?
O argumento aqui é: não confie nas fontes, verifique o conteúdo que elas entregam. É justo dizer que, uma vez que um conteúdo malicioso se origina de uma fonte, essa fonte deixa de ser considerada confiável. Mas para que isso seja acionável, você ainda precisa verificar o que a fonte está fazendo.
O Subresource Integrity Falha na Web Dinâmica de Hoje
Para garantir conteúdo previsível em scripts, o SRI representou um grande avanço. O Subresource Integrity é eficaz para scripts estáticos com controle de versão, mas falha com scripts dinâmicos.
A maioria dos scripts carregados no client-side em 2025 é dinâmica, e por boas razões. Eles adaptam o conteúdo com base na localização geográfica do usuário, tipo de dispositivo, recursos do navegador ou requisitos de personalização. Cada uma dessas mudanças legítimas pode quebrar o hash utilizado pelo SRI.
Combinando SRI com uma Ferramenta de Monitoramento de Scripts Dinâmicos
Com o cside, o SRI pode ser aplicado de forma mais eficaz. O cside detecta scripts estáticos e ajuda a gerar os cabeçalhos SRI para eles. Scripts dinâmicos são tratados de forma diferente, com outros protocolos de segurança, como um mecanismo de inspeção de scripts baseado em IA.
Ferramentas de Scanner Não Conseguem Verificar a Integridade de Scripts
Scripts client-side são servidos de formas diferentes com base em User Agents, IPs de requisição, países, horário do dia, etc. — qualquer elemento dentro de um cabeçalho de requisição pode resultar em uma resposta diferente do servidor. Não é incomum que um script client-side sirva conteúdos diferentes de forma aleatória.
Por causa dessa variabilidade, abordagens baseadas em scanners não são um método confiável para verificar a integridade de scripts. Atacantes conseguem detectar facilmente quando um crawler ou ferramenta automatizada está solicitando o arquivo. Eles simplesmente servem uma versão limpa ao scanner e entregam o payload malicioso a um subconjunto específico de usuários reais.
Atualizações no Subresource Integrity
Desde o lançamento inicial do SRI, diversas melhorias foram feitas. Uma preocupação comum com o SRI era que, se o hash de um script não correspondesse, o script seria bloqueado, mas nenhuma API de relatório estava disponível — resultando em uma página quebrada sem nenhum alerta para o proprietário do site.
No entanto, com a especificação atualizada de Integrity Policy, isso agora é possível.
O cside contribui para melhorias no SRI
Mais especificações estão sendo propostas para o SRI, e o cside contribuiu com algumas delas. Como membro ativo do w3c (a principal organização que desenvolve padrões para a web), o cside apresentou sugestões para especificações melhores para o gerenciamento dinâmico de hashes de scripts.
No estado atual, hashes de scripts codificados diretamente trazem desafios que a maioria das empresas não pode arcar. Até lá, o SRI pode ser uma ferramenta útil para scripts estáticos ou previsíveis, mas não é a solução completa para garantir a integridade de scripts.
Como Verificar a Integridade de Scripts para Conformidade
Use uma Ferramenta de Segurança Client-side
Embora a definição exata de "integridade de scripts" seja interpretada de forma diferente entre os frameworks, um ponto é amplamente consensual: ferramentas de fornecedores prontas para uso são o caminho mais prático para verificar a integridade de scripts. Desenvolver essas capacidades internamente levaria meses e precisaria de manutenção contínua à medida que os atacantes mudam de técnicas.
Durante nosso webinar recente com a BARR Advisory, o consultor de conformidade Kyle Kofsky foi direto: a recomendação padrão para organizações que estão abordando os requisitos de integridade de scripts do PCI DSS 6.4.3 e 11.6.1 é adotar uma solução de fornecedor homologada.
Use o cside para Verificar a Integridade de Scripts
Com a solução de segurança de scripts do cside, você simplesmente adiciona um script ao seu site e nós monitoramos o comportamento de cada script presente nele. Você obtém um dashboard para entender quais dados cada script acessa, para onde envia esses dados, como esses comportamentos mudaram ao longo do tempo, além de informações sobre a origem do script e se há melhorias de desempenho possíveis.
Essas informações são documentadas automaticamente no formato exigido pelos seus requisitos de conformidade — seja padrões de privacidade como GDPR e CCPA, ou padrões de segurança voltados ao combate de scripts maliciosos como PCI DSS 4.0.1, ISO 27001 e HIPAA. Nossa solução atende e supera esses requisitos e é homologada pelos assessores de maior prestígio do setor. Confira nosso White Paper com a Vikingcloud aqui.
O cside quer tornar a web mais segura. Ao usar nossa solução, você fortalece o time para pressionar os órgãos do setor a permitir mecanismos de segurança mais fáceis e robustos nos navegadores. Somos transparentes sobre as limitações e trabalhamos para tornar o mundo mais seguro. Nossa motivação: proteger nossos amigos e familiares da ansiedade com segurança online e poupar os merchants de precisar aumentar preços para compensar fraudes.
