SRI

SRI (Subresource Integrity) é um recurso HTML5 que permite fixar o hash SHA-256/SHA-384/SHA-512 de um recurso externo. O navegador calcula o hash no download e recusa executar o recurso se os hashes não coincidirem.

Exemplo: <script src="https://cdn.example/lib.js" integrity="sha384-AbC..." crossorigin="anonymous"></script>

O que isso protege: um comprometimento de CDN. Se um atacante assumir o controle da CDN e servir JavaScript modificado, todo site que incluir o script via SRI recusará executar a versão modificada. Sem SRI, todo site recebe silenciosamente o payload malicioso.

A contrapartida: fixar um hash significa que você não pode atualizar o recurso sem atualizar cada página que o referencia. Para assets de terceiros que você mesmo está construindo, SRI é uma defesa de baixo custo. Para scripts de CDN de terceiros (jQuery, tags de análise), é uma vitória de segurança significativa ao custo de propagação de atualização mais lenta.

SRI requer crossorigin="anonymous" na tag mais um header CORS na resposta da CDN — o navegador precisa conseguir ler a resposta de forma opaca.

Incidentes reais que o SRI teria impedido: a família de ataques Magecart de skimming de cartões comprometeu repetidamente JavaScript de terceiros hospedado por fornecedores confiáveis (BrowserAloud, Inbenta, Picreel) e injetou código para roubo de cartões que foi carregado em milhares de páginas de checkout de e-commerce. A violação da Ticketmaster em 2018 e a da British Airways em 2018 envolveram atacantes modificando scripts em hosts que os sites afetados incluíam via <script src="…">. SRI é a mitigação específica: se esses sites tivessem fixado o hash de integridade da versão do script que pretendiam carregar, o payload modificado teria falhado na verificação e o navegador teria recusado executá-lo.

Como gerar e rotacionar hashes SRI pragmaticamente: para arquivos que você possui, o pipeline de build deve emitir hashes SRI junto com o pacote de assets e incorporá-los no HTML no momento do template (Next.js, Vite e Webpack suportam isso com plugins). Para bibliotecas de terceiros, o fluxo de trabalho recomendado é bloquear em uma versão específica, copiar o arquivo para sua própria CDN e fixar com SRI — confiar que a CDN upstream mantenha os mesmos bytes disponíveis na mesma URL é arriscado ao longo de meses. O atributo integrity aceita múltiplos hashes separados por espaços, permitindo transições de algoritmo de hash (envie SHA-384 e SHA-512 juntos; o navegador escolhe o que suportar). Relacionado: CSP, SHA-256. Referência: W3C — Integridade de Sub-recurso.

Exemplo prático

Você quer incluir jQuery 3.7.1 de uma CDN com proteção SRI. Calcule o hash SHA-384 do arquivo: openssl dgst -sha384 -binary jquery-3.7.1.min.js | openssl base64 -A produz algo como Bu3qSpvxnAdMaOTsigCcfqUyJYvP7AbsxRRpzqj7M1V2OuoP1bb98c8MQYIPHzxc. Incorpore: <script src="https://code.jquery.com/jquery-3.7.1.min.js" integrity="sha384-Bu3qSpvxnAdMaOTsigCcfqUyJYvP7AbsxRRpzqj7M1V2OuoP1bb98c8MQYIPHzxc" crossorigin="anonymous"></script>. No carregamento da página, o navegador busca o arquivo, calcula seu SHA-384, codifica em base64 e compara com o atributo integrity. Se a CDN servir um arquivo adulterado — mesmo uma mudança de um único byte — os hashes divergem, o navegador bloqueia a execução e um SecurityError aparece no DevTools. A página ainda renderiza; apenas o script com falha de integridade é suprimido.

Quando e por que isso importa

Sempre que seu site carrega JavaScript de um domínio que você não controla, você está confiando nos operadores desse domínio, seu provedor de CDN, seu DNS e cada etapa do TLS no caminho. Essa confiança é empiricamente mal depositada com frequência suficiente para importar: comprometimentos da cadeia de fornecimento afetando pacotes npm, plugins jQuery, contêineres GTM e scripts de análise atingiram sites importantes a uma taxa de vários por ano. SRI é a defesa que não requer confiança no terceiro. A estratégia pragmática de implantação: fixe com SRI scripts de terceiros que você carrega por URL (bibliotecas hospedadas em CDN, widgets incorporados), mas não scripts que você agrupa e entrega de sua própria origem onde você controla os bytes. Combine com CSP require-sri-for script (proposto mas ainda não amplamente implementado) ou script-src com hashes permitidos explícitos para defesa em profundidade. Referência: MDN — Integridade de Sub-recurso.