Uma landing page criada por IA pode importar uma biblioteca, um player ou uma folha de estilos direto de uma CDN. O arquivo fica fora do seu pacote, mas executa ou altera a página como se fosse parte do projeto. Se o conteúdo remoto mudar, seu repositório pode continuar igual enquanto a experiência publicada muda.

Subresource Integrity, ou SRI, permite declarar no HTML o hash criptográfico exato de um script ou stylesheet externo. O navegador baixa o recurso, calcula o hash e só o utiliza quando o resultado corresponde ao valor aprovado.

SRI não torna uma dependência confiável por si só. Ele transforma uma versão remota específica em uma decisão verificável — e faz uma alteração inesperada falhar de maneira visível.

Quando SRI resolve um problema real

SRI é adequado quando o recurso:

  • é carregado por <script src> ou por um <link> compatível;
  • tem uma URL versionada e conteúdo estável;
  • é servido por HTTPS;
  • permite o carregamento cross-origin necessário;
  • pode falhar sem apagar o conteúdo essencial da página;
  • possui um processo claro de atualização do hash.

A documentação da MDN sobre Subresource Integrity explica que o navegador compara o arquivo recebido com os hashes do atributo integrity antes de executar o script ou aplicar o stylesheet. Se nenhum hash corresponder, o recurso é recusado.

Esse controle é útil contra mudanças inesperadas na origem remota, inclusive em cenários de comprometimento da cadeia de fornecimento. Ele não avalia se o código aprovado é seguro, se coleta dados demais ou se deveria estar na página. Faça primeiro o inventário descrito no guia de scripts de terceiros.

Comece pela build que será publicada

Procure dependências externas no pacote final, não apenas nos arquivos-fonte:

Terminal window
rg -n 'https?://|<script|<link' dist

Confirme cada ocorrência no HTML gerado. Bundlers podem copiar uma dependência para um asset local, injetar tags durante a build ou eliminar imports que não foram usados.

Para cada recurso remoto, registre:

Campo Evidência esperada
URL exata endereço completo usado pela build
Versão número ou identificador imutável
Finalidade capacidade que o recurso entrega
Proprietário pessoa que aprova atualizações
Hash atual algoritmo e valor aprovados
CORS header observado na resposta
Fallback comportamento da página se houver bloqueio

Uma URL com latest, um caminho que muda sem versionamento ou um endpoint que gera conteúdo por usuário não combina com um hash fixo. Nesses casos, prefira uma versão imutável, hospede o arquivo aprovado no próprio pacote ou remova a dependência.

Gere o hash do arquivo real

Baixe ou obtenha o mesmo arquivo que a página carregará e calcule o hash sobre seus bytes exatos. Um exemplo com SHA-384:

Terminal window
openssl dgst -sha384 -binary biblioteca.min.js | openssl base64 -A

O valor do atributo recebe o prefixo do algoritmo:

<script
  src="https://cdn.exemplo.com/biblioteca/4.2.0/biblioteca.min.js"
  integrity="sha384-VALOR_BASE64_CALCULADO"
  crossorigin="anonymous"
  defer
></script>

Para uma folha de estilos:

<link
  rel="stylesheet"
  href="https://cdn.exemplo.com/biblioteca/4.2.0/biblioteca.min.css"
  integrity="sha384-VALOR_BASE64_CALCULADO"
  crossorigin="anonymous"
/>

Não reutilize o hash de uma versão parecida. Minificação, comentários, espaços ou uma recompilação alteram os bytes e, portanto, o resultado.

Os algoritmos atualmente aceitos incluem SHA-256, SHA-384 e SHA-512. Escolher SHA-384 como padrão operacional é comum, mas o ponto decisivo é registrar o algoritmo, calcular sobre o artefato correto e testar no navegador.

Entenda por que crossorigin importa

Para recursos de outra origem, SRI depende de uma resposta CORS compatível. A origem que fornece o arquivo precisa permitir a leitura usada na verificação, normalmente com Access-Control-Allow-Origin adequado.

No HTML, use crossorigin="anonymous" quando o fornecedor documentar esse fluxo. Depois confira a resposta real:

Terminal window
curl -sS -D - -o /dev/null \
  -H 'Origin: https://www.exemplo.com' \
  https://cdn.exemplo.com/biblioteca/4.2.0/biblioteca.min.js

Use no header Origin exatamente o scheme e o host da página publicada. Algumas CDNs variam Access-Control-Allow-Origin conforme a origem recebida; uma requisição sem esse header não reproduz a troca feita pelo navegador.

Se o servidor não oferecer CORS compatível, adicionar integrity e crossorigin pode bloquear um recurso que antes carregava. Não contorne isso removendo o hash depois do erro. Decida entre:

  1. usar uma origem oficial compatível;
  2. hospedar a versão revisada no próprio pacote;
  3. substituir a dependência;
  4. aceitar formalmente que SRI não se aplica e registrar outro controle.

Não configure Access-Control-Allow-Origin no seu próprio site esperando alterar a resposta da CDN. CORS precisa ser emitido pela origem que serve o recurso.

Teste a falha deliberadamente

Um teste positivo prova que o hash atual corresponde ao arquivo. Um teste negativo prova que o navegador realmente bloqueia a divergência.

Em um ambiente local de teste:

  1. carregue a página com o hash correto;
  2. confirme a requisição e a execução no Network e no console;
  3. altere um caractere do valor de integrity;
  4. recarregue sem cache;
  5. confirme que o recurso foi recusado;
  6. percorra a jornada principal sem ele;
  7. restaure o hash correto antes de publicar.

Esse ensaio revela dependências críticas escondidas. Se o menu, o formulário ou todo o conteúdo desaparecer quando uma biblioteca externa falha, a página precisa de degradação melhor — não apenas de um hash correto.

Planeje atualizações sem abrir uma janela insegura

Quando o fornecedor publicar uma nova versão:

  1. leia as notas e confirme a origem oficial;
  2. baixe o novo arquivo por um canal seguro;
  3. revise a mudança e a licença;
  4. calcule o novo hash;
  5. atualize URL e integrity no mesmo commit;
  6. execute testes positivos e negativos;
  7. publique e verifique a URL final;
  8. registre a versão aprovada.

Não atualize apenas a URL nem remova temporariamente integrity para “destravar” o deploy. A versão e o hash formam uma unidade.

Algumas CDNs publicam mais de um hash durante uma transição. O atributo aceita uma lista separada por espaços, mas isso amplia o conjunto de conteúdos autorizados. Mantenha múltiplos valores apenas durante uma migração deliberada e remova o anterior quando ele deixar de ser necessário.

Combine SRI com CSP sem confundir funções

SRI responde: “os bytes recebidos são os que aprovamos?”. Content Security Policy responde: “esta origem ou este tipo de recurso pode ser carregado aqui?”.

Uma página pode ter CSP permitindo a CDN e ainda receber um arquivo alterado dessa origem. Também pode ter um hash SRI correto e ser vulnerável a um script inline injetado que a CSP permissiva aceita.

Use os dois controles quando fizer sentido:

  • CSP limita origens, conexões e capacidades;
  • SRI fixa o conteúdo de recursos externos compatíveis;
  • versionamento torna a atualização explícita;
  • inventário documenta finalidade, dados e responsável;
  • testes confirmam que a jornada sobrevive a bloqueios.

O guia de Content Security Policy para landing pages mostra como partir do inventário e avançar de report-only para enforcement.

Não confunda SRI com hashes de CSP

Os dois mecanismos usam hashes, mas protegem coisas diferentes.

  • O atributo integrity fica no elemento que carrega um recurso externo e valida o arquivo baixado.
  • Um hash em script-src ou style-src autoriza um bloco ou recurso segundo a política CSP.

Não copie automaticamente um valor de um mecanismo para o outro. Confirme sintaxe, conteúdo coberto e compatibilidade de cada caso. Uma build pode transformar o HTML ou o JavaScript e invalidar a hipótese inicial.

Publique o pacote e verifique a URL final

Siga o contrato de Publicação e envie a build que contém os atributos integrity e crossorigin. Depois abra a URL publicada em uma sessão limpa.

Confira:

  • HTML servido contém a URL e o hash aprovados;
  • o recurso responde por HTTPS;
  • CORS continua compatível;
  • console não mostra erro de integridade;
  • o arquivo carregado tem a versão esperada;
  • a jornada principal funciona;
  • um bloqueio simulado ainda produz degradação aceitável.

Se a página usa domínio próprio, espere o hostname ficar active e teste exatamente a URL HTTPS que será entregue. O guia de verificação de domínio e SSL organiza essa etapa.

Prompt copiável para o agente

Revise os scripts e stylesheets externos desta landing page para uso de SRI.


Fonte: [caminho]
Build publicável: [pasta]
URL final: [URL]


Para cada recurso externo:
- registre URL, versão, finalidade e responsável;
- confirme se o conteúdo é estável e se a origem oferece CORS compatível;
- calcule o hash a partir do arquivo exato;
- proponha integrity e crossorigin sem alterar outros recursos;
- teste o carregamento com o hash correto e o bloqueio com um hash inválido;
- avalie a jornada quando o recurso não carrega.


Não use URL latest.
Não copie hash de exemplo.
Não remova SRI para silenciar erro.
Não publique antes de devolver o diff e as evidências.

Checklist final

  • recursos externos inventariados na build;
  • dependências desnecessárias removidas;
  • URLs apontam para versões estáveis;
  • hashes foram calculados sobre os bytes reais;
  • integrity usa algoritmo e base64 corretos;
  • crossorigin e CORS foram confirmados;
  • teste positivo passou sem cache;
  • teste negativo bloqueou o recurso;
  • jornada principal degrada de forma aceitável;
  • URL, versão e hash mudam no mesmo commit;
  • CSP e inventário continuam coerentes;
  • URL publicada foi verificada.

SRI é pequeno no HTML, mas exige disciplina no ciclo de atualização. O benefício aparece quando uma mudança fora do repositório deixa de ser silenciosa e passa a exigir uma nova aprovação explícita.