TL;DR: Hashes SRI para scripts dinâmicos de terceiros
- SRI fixa ficheiros estáticos: O SRI fixa um hash a um ficheiro estático. Os fornecedores terceiros modernos entregam código que muda a cada carregamento. Os comerciantes carregam dezenas destes scripts por cada checkout. Fixar algo que não fica parado é um item de checklist de conformidade, não um controlo.
- O registo de auditoria: A Mastercard aponta o e-skimming como a principal fonte de skimming de cartões de crédito, e o Client-side Attack Report da cside contabilizou mais de 380 000 sites afetados em 2025. O cside gera hashes SRI para os scripts estáticos, monitoriza o comportamento dos scripts dinâmicos e fornece o registo de auditoria que o PCI DSS 6.4.3 e 11.6.1 realmente exigem.
- SRI é uma camada: Não trate o SRI como o objetivo final, trate-o como uma camada. Se a sua estratégia de integridade termina nos hashes, um domínio de fornecedor expirado ou um pipeline de CI/CD comprometido continua a permitir que um atacante reescreva o comportamento de pagamento dentro do navegador na próxima terça-feira.
Sem tempo? Veja o bloqueio de Magecart e skimmers no navegador da cside. Cobre tudo o que se segue numa única implementação.
O termo "integridade de scripts" é utilizado em requisitos de conformidade como o PCI DSS 4.0.1, a ISO 27001, a HIPAA e outros frameworks — mas o que significa este termo e o que é esperado?
Porque É Que a Integridade de Scripts Importa para Comerciantes e Empresas de E-commerce
Os recursos carregados de terceiros têm origem numa fonte externa. Confiar incondicionalmente numa fonte não é seguro no espaço em rápida evolução da internet. As empresas SaaS surgem e desaparecem e, infelizmente, muitas não têm um plano de contingência para os domínios que utilizavam nos ambientes de produção dos seus clientes.
No passado, ocorreram diversos incidentes que afetaram consumidores desavisados em todo o mundo.
As injeções através do sequestro de uma fonte de terceiros podem ocorrer de várias formas.
- Engenharia social
- Sequestros direcionados a pipelines de CI/CD
- Dependências open source maliciosas
- Injeções de malware ao nível da máquina nos dispositivos dos programadores
- Aquisição de um domínio expirado
Não precisa de ser um ataque avançado à cadeia de fornecimento; pode começar com um ponto de entrada bastante trivial (como um domínio expirado) que dá aos atacantes uma abertura discreta para manipular o código em execução no seu site sem que ninguém se aperceba.
Da próxima vez que os seus utilizadores introduzirem informações nas suas páginas, dados sensíveis podem ser recolhidos através de iframes injetados colocados sobre elementos de pagamento (web skimming), cadeias de redirecionamento forçadas, sequestro de cookies de afiliados, entrega de malware ao nível do dispositivo, ou até exploração de zero-days no navegador.
Integridade de Scripts: Para Requisitos de Conformidade
Os frameworks de conformidade esperam cada vez mais que as empresas monitorizem a integridade e o histórico de alterações dos scripts client-side.
- Para o PCI DSS 4.0.1: a validação da integridade de scripts é obrigatória para cumprir os requisitos de deteção de alterações 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
Segundo a Mastercard, a principal fonte de skimming de cartões de crédito é o e-skimming, que ocorre do lado do cliente. Os scripts comprometidos são uma porta aberta para que os 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).
Gestão da Integridade de Scripts: Para Empresas de E-commerce
Qualquer comerciante que processe um elevado volume de transações online é um alvo prioritário para a exploração client-side.
- Os sites de e-commerce modernos carregam dezenas de scripts de terceiros. Os comerciantes precisam de visibilidade sobre o que esses scripts estão a fazer, quando mudam e se essas alterações correspondem ao comportamento pretendido.
O Que É a Integridade de Scripts
Equívocos Sobre o Termo
O termo "integridade de scripts" é provavelmente usado devido ao priming lexical relativamente ao método de gestão "Subresource Integrity" referenciado nos principais frameworks de conformidade. O priming lexical consiste em reutilizar palavras com que nos deparámos recentemente — todos o fazemos.
No entanto, usar a palavra "integridade" isoladamente pode gerar confusão e está aberto a interpretação.
O Que Qualifica um Script Como Tendo (ou Não) Integridade?
Monitorização do Comportamento para a Integridade de Scripts
Neste contexto, integridade pode significar "garantir que os scripts não têm um comportamento malicioso". O problema é que a exfiltração de dados, por si só, não é um comportamento malicioso, tal como redirecionar também não o é. Muitos scripts de terceiros fazem isto por razões válidas, o que torna muito difícil fiscalizar as alterações.
Monitorização de Alterações a Scripts para a Integridade de Scripts
O fator de mudança é aquilo a que os frameworks de conformidade mais habitualmente se referem: garantir que, quando um script muda, essas alterações correspondem à utilização esperada do script.
O Que É o 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 numa aplicação web. O SRI existe desde 2015, quando a Google e a Mozilla o adotaram nos seus navegadores, tendo sido posteriormente reconhecido pelo w3c em 2016.
Objetivo do Subresource Integrity (SRI)
O objetivo do SRI era impedir que recursos estáticos carregados no lado do cliente, como ativos com controlo de versões, passassem subitamente a comportar-se de forma dinâmica. Exemplo: jQuery versão x.
O SRI visa o "fator de mudança", verificando se o conteúdo de um script permanece idêntico à sua versão conhecida e de confiança.
Porque É Que o SRI Foi Adicionado ao CSP
Ao longo dos anos, cada vez mais funcionalidades do SRI foram sendo adicionadas às Content Security Policies (CSP). O que levantou a questão: porquê ter os dois? A segurança assenta em camadas, por isso é bom ter opções. No entanto, a limitação do CSP de não interagir ativamente com o conteúdo dos scripts levou ao passo lógico seguinte: considerar a adição de hashes à especificação.
Durante algum tempo, o CSP confiava apenas nas fontes, o que originou o problema abaixo. Imagine que apareciam duas caixas à sua porta. Ambas do mesmo remetente, mas uma contém um cachorrinho fofo e a outra uma bomba de glitter.
Diga-me, só pelo endereço do remetente, qual é qual?
O argumento aqui é: não confie nas fontes, verifique antes o conteúdo que estas servem. É justo dizer que, assim que um conteúdo malicioso tem origem numa fonte, essa fonte deixa de ser considerada fiável. Mas, para que isso seja acionável, ainda é preciso verificar o que a fonte faz.
O Subresource Integrity Falha na Web Dinâmica Atual
Para efeitos de conteúdo previsível em scripts, o SRI representou um enorme salto em frente. O Subresource Integrity é eficaz para scripts estáticos e com controlo de versões, mas falha com scripts dinâmicos.
A maioria dos scripts carregados no lado do cliente em 2025 é dinâmica, e por boas razões. Adaptam o conteúdo consoante a localização geográfica do utilizador, o tipo de dispositivo, as funcionalidades do navegador ou os requisitos de personalização. Cada uma destas alterações legítimas pode quebrar o hash utilizado pelo SRI.
Combinar o SRI com uma Ferramenta de Monitorização de Scripts Dinâmicos
Com o cside, o SRI pode ser aplicado de forma mais eficaz. O cside deteta scripts estáticos e ajuda a gerar os cabeçalhos SRI correspondentes. Os scripts dinâmicos são tratados de forma diferente, com outros protocolos de segurança, como um motor de inspeção de scripts baseado em IA.
As Ferramentas de Scanner Não Conseguem Verificar a Integridade de Scripts
Os scripts client-side servem conteúdo de forma diferente consoante o User Agent, o IP do pedido, o país, a hora do dia, etc. — qualquer elemento dentro de um cabeçalho de pedido pode originar uma resposta diferente do lado do servidor. Não é incomum que um script client-side sirva conteúdos diferentes de forma aleatória.
Devido a esta variabilidade, as abordagens baseadas em scanners não são um método fiável para verificar a integridade de scripts. Os atacantes conseguem detetar facilmente quando um crawler ou uma ferramenta automatizada está a pedir o ficheiro. Servem simplesmente uma versão limpa ao scanner e entregam a carga maliciosa a um subconjunto específico de utilizadores reais.
Atualizações ao Subresource Integrity
Desde o lançamento inicial do SRI, foram feitas várias melhorias. Uma preocupação comum com o SRI era que, se o hash de um script não correspondesse, o script era bloqueado, mas não existia nenhuma API de relatório disponível, o que resultava numa página quebrada sem qualquer alerta para o proprietário do site.
No entanto, com a especificação atualizada de Integrity Policy, isto já é possível.
O cside Contribui para Melhorias no SRI
Estão a ser propostas mais especificações para o SRI, para as quais o cside tem contribuído. Como membro ativo do w3c (a principal organização que desenvolve normas para a web), o cside tem apresentado sugestões para melhores especificações relativas à gestão dinâmica de hashes de scripts.
No estado atual, os hashes de scripts codificados de forma fixa acarretam desafios que a maioria das empresas não pode suportar. 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
Utilize uma Ferramenta de Segurança Client-side
Embora a definição exata de "integridade de scripts" seja interpretada de forma diferente consoante o framework, há um ponto amplamente consensual: as ferramentas de fornecedores já prontas são o caminho mais prático para verificar a integridade de scripts. Construir estas capacidades internamente demoraria meses e exigiria manutenção contínua, à medida que os atacantes alteram as suas técnicas.
Durante o nosso webinar recente com a BARR Advisory, o consultor de conformidade Kyle Kofsky foi direto: a recomendação padrão para as organizações que abordam os requisitos de integridade de scripts do PCI DSS 6.4.3 e 11.6.1 é adotar uma solução de fornecedor devidamente validada.
Utilize o cside para Verificar a Integridade de Scripts
Com a solução de segurança de scripts do cside, basta adicionar um script ao seu site e nós monitorizamos o comportamento de todos os scripts presentes nele. Tem acesso a um dashboard para perceber que dados cada script acede, para onde os envia, como esses comportamentos evoluíram ao longo do tempo, bem como a origem do script e se é possível fazer melhorias de desempenho.
Esta informação é documentada automaticamente no formato exigido pelos seus requisitos de conformidade — sejam normas de privacidade como o RGPD e o CCPA, ou normas de segurança destinadas a combater scripts maliciosos, como o PCI DSS 4.0.1, a ISO 27001 e a HIPAA. A nossa solução cumpre e supera estes requisitos, e é validada pelos avaliadores de topo do setor. Veja o nosso White Paper com a Vikingcloud aqui.
O cside quer tornar a web mais segura. Ao utilizar a nossa solução, capacita a sua equipa para pressionar os organismos do setor a permitirem mecanismos de segurança mais fáceis e robustos nos navegadores. Somos transparentes quanto às limitações e trabalhamos para tornar o mundo mais seguro. A nossa motivação: poupar os nossos amigos e familiares à ansiedade da segurança online e evitar que os comerciantes tenham de aumentar os preços para compensar a fraude.
