Os scripts de terceiros são um risco de cadeia de fornecimento
Um script de terceiros é código que não escreveu, servido por uma empresa que não controla, executado dentro das suas páginas com as sessões dos seus utilizadores: em termos de cadeia de fornecimento, é uma dependência que pode mudar o seu próprio código a qualquer momento, sem lançamento, sem revisão e sem aviso. Em outubro de 2026 esse risco abstrato tornou-se uma perda concreta, segundo os relatos, quando um script de monitorização de desempenho carregado por um grande site de negociação foi trocado por um construído para drenar os seus utilizadores. Este artigo percorre o que foi relatado, o que a Subresource Integrity realmente detém, porque fixar uma versão precede o cálculo do seu hash, quando o autoalojamento é a melhor resposta e a rotina curta de auditoria que mantém o inventário honesto.
O que aconteceu na Polymarket, segundo os relatos
A 29 de outubro de 2026, segundo os relatos, o site internacional da Polymarket pôs a negociação em modo só de cancelamento depois de os utilizadores relatarem fundos a sair das suas contas, e a negociação recomeçou cerca de uma hora depois. As próprias declarações da empresa, segundo os relatos, atribuíram o incidente a um fornecedor externo comprometido, disseram que o assunto fora remetido às autoridades e prometeram ressarcir os utilizadores afetados. Os relatórios baseados na análise pós-incidente da empresa, de 30 de outubro, situaram o montante levado no ataque em cerca de 2,7 milhões de dólares, com reembolsos totais de 3,9 milhões uma vez incluídos os pagamentos de boa vontade pelas perdas causadas pela pausa da negociação; análises independentes em cadeia citadas na cobertura rastrearam um valor semelhante, cerca de 2,7 milhões, repartido por várias centenas de carteiras. Nenhum destes valores está verificado de forma independente aqui: são os valores dos relatos, e este artigo trata-os como tal.
O mecanismo, segundo os relatos, é a parte que se generaliza. Os investigadores citados na cobertura ligaram o código malicioso ao script de monitorização de utilizadores reais (RUM) de um fornecedor de desempenho web: um ficheiro pequeno cujo único trabalho é medir a velocidade de carregamento das páginas nos navegadores dos visitantes, incorporado por cliente a partir do CDN do fornecedor. Esse ficheiro, segundo os relatos, foi substituído por uma carga escrita especificamente para o site alvo: trabalhava dentro de sessões iniciadas, usava a própria maquinaria de negociação do site já presente na página e movia posições e fundos para um destino controlado pelo atacante. Segundo os relatos, não houve qualquer falha de contrato inteligente nem palavras-passe ou chaves privadas roubadas: o script trocado era simplesmente a página, no que ao navegador diz respeito. Que cada detalhe desse relato sobreviva a um escrutínio posterior é, para a lição, irrelevante: a forma do ataque — um ficheiro de fornecedor, trocado uma vez, executado por cada visitante — é a forma padrão desta classe de incidentes.
Um script de terceiros é o seu código, com o processo de lançamento de outra pessoa
Não há nenhuma caixa de areia numa etiqueta script clássica. O código carregado do CDN de um fornecedor é executado na sua origem com o mesmo acesso que o seu próprio pacote: pode ler e mudar o DOM, ler valores de formulários enquanto são escritos, chamar as suas API com a sessão do utilizador e enviar o que encontrar para qualquer parte. O guia da OWASP sobre JavaScript de terceiros nomeia os três riscos sem rodeios — perda de controlo sobre as alterações da aplicação cliente, execução de código arbitrário nos sistemas cliente e divulgação de informação sensível a terceiros — e os três derivam desse único facto. O seu processo de revisão, o seu congelamento de código e o seu comité de alterações terminam na sua própria construção; o ficheiro do fornecedor pode ser editado pelo fornecedor, por um atacante que comprometa o fornecedor, ou por quem volte a registar o domínio do fornecedor se ele alguma vez expirar.
Essa assimetria é a razão pela qual «confiamos neste fornecedor» não é um controlo. A confiança decide de quem é o script que aceita hoje; nada diz sobre o que esse URL servirá amanhã, e não lhe dá qualquer sinal quando o conteúdo muda. Os controlos que funcionam são os que removem a confiança (servir o ficheiro você mesmo), a restringem (uma Content-Security-Policy que limite o que qualquer script pode fazer e para onde pode enviar dados) ou a verificam mecanicamente em cada carregamento — que é para isso que serve a Subresource Integrity. Comece pelo inventário: não pode aplicar nenhum dos três a scripts que não sabe que tem, e a maioria dos sites tem mais do que os seus proprietários esperam, uma vez contadas as etiquetas de marketing, os widgets de suporte e os códigos de monitorização.
O que o SRI detém — e o que não detém
A Subresource Integrity é um mecanismo do navegador, especificado pelo W3C e documentado pela MDN: a página declara o hash criptográfico do ficheiro que espera no atributo integrity da etiqueta, o navegador calcula o hash do que realmente descarregou e, perante qualquer diferença, recusa-se a executar o ficheiro. Para um ficheiro de outra origem, a etiqueta também precisa de crossorigin="anonymous" e o servidor deve enviar cabeçalhos CORS, para que o navegador possa fazer a verificação. Aplicado a uma biblioteca fixa, o SRI transforma uma troca silenciosa numa falha ruidosa: o ficheiro que chega ou é, byte a byte, o ficheiro que reviu, ou não é executado de todo. Se o script de monitorização do incidente relatado tivesse sido um ficheiro fixo carregado dessa maneira, uma carga trocada teria falhado a verificação em vez de ser executada nas sessões dos utilizadores — esse condicional é a forma honesta da afirmação, porque se esse código concreto era suscetível de hash é uma questão sobre um ficheiro dinâmico por cliente, que é exatamente o caso difícil abaixo.
O que o SRI não detém é igualmente importante. Não ajuda com scripts cujo conteúdo é suposto mudar — contentores de gestores de etiquetas, carregadores de personalização e consentimento, ficheiros gerados por cliente — porque não há nenhum hash estável para fixar. Não julga o ficheiro a que calculou o hash: um script entregue fielmente pode continuar a ser curioso, descuidado ou malicioso por conceção, e o SRI verificá-lo-á de bom grado para sempre. Não cobre os scripts injetados em tempo de execução por outros scripts, não protege os ficheiros próprios servidos a partir da sua própria infraestrutura e nada faz sobre os dados que um script legítimo recolhe depois de executado. O SRI é uma garantia mecânica — estes bytes exatos, ou nada — e ganha o seu lugar ao lado de CSP, da revisão de fornecedores e da minimização de quantos terceiros obtêm acesso ao nível da sessão desde o início, e não em seu lugar. A verificação de cabeçalhos de segurança deste site classifica o lado CSP desse par.
Fixe a versão, ou o hash não se pode sustentar
O SRI tem uma pré-condição que faz fracassar mais auditorias do que a malícia: o URL deve devolver sempre os mesmos bytes. Um hash fixado sobre um endereço latest, uma versão maior flutuante ou um ficheiro por cliente que o fornecedor regenera é um hash que se parte assim que o fornecedor publica uma atualização — e as equipas a quem uma falha de SRI autoinfligida acordou uma vez tendem a retirar o atributo em vez de corrigir o endereço, deixando a página pior do que sem medição. A ordem duradoura é a inversa: primeiro mude o URL para nomear a versão exata ([email protected], /v2.4.0/), reveja essa versão uma vez e depois calcule o hash desse ficheiro exato. As subidas de versão tornam-se então eventos deliberados — URL novo, hash novo, um commit — em vez de mudanças ambientais que descobre através dos seus utilizadores.
Fixar tem um custo, e a honestidade exige nomeá-lo: uma biblioteca fixada já não recebe correções de segurança silenciosas do fornecedor, por isso fixar cria o dever de acompanhar os lançamentos e subir de versão de propósito, o mesmo dever que qualquer dependência vendorizada traz. É um dever gerível — as notas de lançamento e um lembrete de calendário cobrem-no — e é estritamente melhor do que a alternativa que substitui, em que as atualizações chegam sem revisão ao ritmo do fornecedor e as ruturas chegam sem aviso ao seu. Trate o par como uma só prática: a fixação torna o conteúdo endereçável, o hash torna-o verificável, e a auditoria garante que nenhum dos dois apodreceu em silêncio — uma cadeia de versão eliminada por uma migração de CMS é tão comum como um hash em falta, e só um pouco mais difícil de notar a olho nu.
Autoalojamento, e a rotina de auditoria
Para os scripts que mais importam, há uma opção mais contundente: servir o ficheiro você mesmo. O autoalojamento remove por completo o servidor, a conta e o domínio do fornecedor da sua cadeia de fornecimento em tempo de execução, permite que o seu canal de implementação normal reveja e calcule o hash do ficheiro, e continua a funcionar quando o CDN do fornecedor não funciona. As contrapartidas são reais: renuncia à cache periférica do fornecedor e às atualizações automáticas, assume o dever de enviar você mesmo as correções de segurança dele, e as licenças de alguns fornecedores ou os seus ficheiros gerados por cliente simplesmente não o permitem — por isso a divisão sensata é por criticidade: autoaloje as bibliotecas pequenas e fixas nas páginas sensíveis; fixe e calcule o hash do que ficar num CDN; governe (com restrições de publicação, revisão de alterações e CSP) as etiquetas dinâmicas que não podem ser fixadas nem alojadas; e elimine, à vista, qualquer script que ninguém consiga justificar. Cada script eliminado é uma cadeia de fornecimento que já não tem.
A rotina que mantém isto verdade é curta o suficiente para ser executada de facto. Trimestralmente — e após qualquer reformulação, migração de CMS ou fornecedor novo — execute a auditoria de scripts de terceiros e SRI sobre os seus modelos de página-chave: lista cada script a que o HTML estático faz referência, quais são de terceiros, quais não têm integridade e quais não estão fixados, e calcula um sha384 pronto a colar para os primeiros hashes em falta que conseguir obter. Corrija por ordem de impacto — primeiro as páginas de sessão, pagamentos e dados pessoais —, verifique depois as camadas de transporte e cabeçalhos com o classificador SSL e a verificação de cabeçalhos, e termine no gestor de etiquetas, cujos scripts injetados em tempo de execução uma auditoria estática não pode ver: reveja a sua lista de publicadores e o seu histórico de alterações com a mesma suspeita que daria a um registo de implementações. Quinze minutos por trimestre, perante uma classe de incidentes cujo custo relatado, no caso acima, ascendeu a milhões em cerca de uma hora.