O que é Subresource Integrity (SRI)? Guia para sites WordPress

Subresource Integrity (SRI) é um padrão de segurança do W3C que permite especificar um hash criptográfico em tags <script> e <link> para que o navegador possa verificar que o arquivo carregado corresponde ao que você espera. Se o arquivo na URL foi modificado, interceptado ou substituído (seja por um atacante, um CDN comprometido, ou até uma atualização acidental), o navegador bloqueia a execução inteiramente. SRI foi padronizado em 2016 e é suportado por todos os principais navegadores. É uma das mitigações mais baratas contra ataques de cadeia de suprimentos em JavaScript de terceiros, que é a fonte dominante de incidentes de violação em sites WordPress em 2026.

Como é um hash SRI, e como adiciono?

Uma tag script com SRI habilitado tem dois atributos extras: integrity e crossorigin:

<script
  src="https://cdn.example.com/jquery-3.7.1.min.js"
  integrity="sha384-1H217gwSVyLSIfaLxHbE7dRb3v4mYCKbpQvzx0cegeju1MVsGrX5xXxAvs/HgeFs"
  crossorigin="anonymous">
</script>

O valor integrity é um hash criptográfico codificado em base64 do conteúdo do arquivo, prefixado com o algoritmo usado (sha256-, sha384-, ou sha512-). SHA-384 é a escolha recomendada em 2026: um bom equilíbrio entre segurança e comprimento do hash. SHA-512 também é aceitável. SHA-256 ainda funciona, mas é considerado o mais fraco dos três; bom para assets não críticos mas não para nada sensível em segurança.

Quando o navegador carrega o arquivo, calcula seu hash e compara ao valor integrity. Se os hashes coincidirem, o script roda. Se diferirem mesmo por um byte, o navegador se recusa a executá-lo e registra um erro no console.

Quais ataques o Subresource Integrity previne?

SRI protege especificamente contra o caso em que um arquivo de terceiros é modificado entre o momento em que você decidiu confiar nele e o momento em que o navegador de um usuário realmente o carrega. Os três cenários mais relevantes para sites WordPress:

• Comprometimento do CDN. Se um atacante invade um CDN (ou o serviço de terceiros cujo CDN você usa) e modifica um arquivo JavaScript, todo site embarcando esse arquivo via <script src> de repente executaria o código do atacante. SRI pega isso imediatamente: o arquivo modificado não corresponde ao hash, o navegador o bloqueia.
• Sequestro de conta no provedor terceiro. Alguém compromete uma conta de analytics, widget de chat ou hospedagem de fontes e publica uma atualização maliciosa para o script que você embarcou. Sem SRI, seu site roda a atualização maliciosa a cada carregamento de página. Com SRI, o script falha silenciosamente até você atualizar o hash, o que significa até você ter pessoalmente reavaliado a nova versão.
• Adulteração em nível de rede. Um atacante man-in-the-middle em uma rede corporativa ou WiFi hostil reescreve um arquivo JavaScript em trânsito para o usuário. HTTPS previne isso para conexões diretas à sua origem, mas um script de terceiros servido por uma tentativa de envenenamento DNS controlada pelo atacante poderia contornar isso. SRI fornece uma verificação de integridade ponta a ponta independente de TLS.

A violação de 2018 da British Airways em que 380.000 clientes tiveram seus dados de pagamento roubados aconteceu porque o atacante modificou um script Modernizr de terceiros que a BA carregava em sua página de checkout. SRI naquela tag script teria parado o ataque no momento em que o arquivo modificado foi carregado. Incidentes similares continuam a acontecer, com ataques estilo Magecart em sites de e-commerce sendo a categoria mais documentada.

A quais arquivos devo adicionar SRI?

SRI é para arquivos de terceiros carregados pela rede. Três categorias importam, em ordem de prioridade:

• Fluxos de pagamento, checkout e login. Qualquer JavaScript que roda numa página onde usuários inserem cartões de crédito, senhas ou outros dados sensíveis é o alvo de mais alta prioridade. Um script comprometido numa página de checkout é o pior cenário. Se seu checkout WooCommerce carrega qualquer coisa de um CDN, cada um desses scripts deveria ter SRI.
• Scripts embarcados globalmente. Qualquer coisa em <head> ou perto do topo de <body> que roda em cada página: tags de analytics, fontes, polyfills, jQuery de um CDN público. Esses rodam antes que o usuário tenha chance de notar algo errado.
• Scripts CDN injetados por plugin. Muitos plugins WordPress (widgets de chat, A/B testing, pixels de marketing) carregam JavaScript remoto. Esses são escritos por terceiros nos quais você implicitamente confiou, e tipicamente não incluem SRI por padrão.

Inversamente, não adicione SRI a arquivos servidos do seu próprio domínio. Se um atacante tem acesso para modificar arquivos no seu servidor de origem, também pode modificar o HTML que declara o hash, então SRI não oferece proteção real. SRI brilha apenas para recursos cross-origin.

Como gero um hash SRI para um script de terceiros?

Três métodos práticos:

1. Use srihash.org. Ferramenta baseada em web. Cole a URL do script, receba de volta a tag <script> completa com atributos integrity e crossorigin. Caminho mais rápido para adições pontuais.
2. OpenSSL na linha de comando. curl -s https://cdn.example.com/file.js | openssl dgst -sha384 -binary | openssl base64 -A emite o hash base64 que você prefixa com sha384-. Útil ao escrever scripts ou trabalhar com arquivos localmente antes do deploy.
3. Verifique a documentação do provedor. CDNs principais (cdnjs.com, jsDelivr) publicam o hash SRI ao lado de cada versão de cada biblioteca que hospedam. Bootstrap, jQuery, Vue, React, etc. todos publicam o valor integrity recomendado em suas páginas oficiais de getting-started. Copie-cole de lá.

Uma ressalva: o hash está vinculado ao conteúdo exato em bytes do arquivo. Se o CDN serve uma versão diferente (porque você usou uma URL como jquery@3 em vez de jquery@3.7.1), o hash não corresponderá e o script bloqueará. Sempre fixe em versões específicas ao usar SRI.

Por que o atributo crossorigin="anonymous" é necessário?

O atributo crossorigin="anonymous" diz ao navegador para buscar o arquivo de terceiros usando CORS, sem enviar cookies ou autenticação. Sem ele, o navegador não consegue ler o corpo de resposta do arquivo para calcular seu hash (uma peculiaridade da política same-origin), e a verificação SRI falha silenciosamente abrindo: o script roda sem ser verificado.

Este é o erro SRI mais comum. As pessoas adicionam integrity mas esquecem crossorigin, depois assumem que seu setup funciona porque o script continua carregando. Sem ambos os atributos, você não tem proteção real. Para verificar: abra DevTools, aba Network, clique no script, olhe a resposta. Se o CDN suporta CORS (essencialmente todos os CDNs públicos modernos suportam), você verá Access-Control-Allow-Origin: * nos cabeçalhos de resposta. Sem esse cabeçalho, SRI não pode funcionar nesse recurso de jeito nenhum.

Como adiciono SRI no WordPress?

Três cenários dependendo de como scripts entram em suas páginas:

Cenário 1: scripts enfileirados pelo WordPress (tema ou plugin)

O core do WordPress suporta SRI via o filtro script_loader_tag. Adicione ao functions.php do seu child theme ou a um pequeno mu-plugin:

add_filter('script_loader_tag', function ($tag, $handle, $src) {
    $sri_hashes = [
        'jquery'    => 'sha384-1H217gwSVyLSIfaLxHbE7dRb3v4mYCKbpQvzx0cegeju1MVsGrX5xXxAvs/HgeFs',
        'bootstrap' => 'sha384-...seu-hash-aqui...',
    ];

    if (isset($sri_hashes[$handle]) && strpos($src, '://') !== false && strpos($src, home_url()) === false) {
        $tag = str_replace(
            ' src=',
            ' integrity="' . $sri_hashes[$handle] . '" crossorigin="anonymous" src=',
            $tag
        );
    }
    return $tag;
}, 10, 3);

Ajuste os nomes de handle e hashes para combinar com seus scripts. As verificações strpos garantem que SRI só é aplicado a scripts carregados de domínios externos, não os seus próprios.

Cenário 2: scripts hardcoded em templates do tema

Se um tema emite diretamente tags <script src="https://..."> no header.php ou em outro lugar, edite essas tags diretamente para adicionar os atributos integrity e crossorigin. Espelhe isso em seu child theme para sobreviver a atualizações do tema pai.

Cenário 3: scripts injetados por JavaScript ou plugins de terceiros em tempo de execução

Widgets de chat, ferramentas de A/B testing e gerenciadores de tags frequentemente injetam tags script dinamicamente. SRI ainda funciona neste caso: o elemento <script> criado dinamicamente deve definir as propriedades integrity e crossOrigin antes do script ser anexado ao DOM. A maioria das versões enterprise dessas ferramentas suportam isso via configuração; os tiers gratuitos tipicamente não. Para injeções de terceiros não gerenciadas, o fallback prático é uma Content Security Policy com require-sri-for script (ainda em rascunho) ou simplesmente auditoria cuidadosa.

Qual é a carga de manutenção do SRI?

Este é o trade-off honesto. SRI é um compromisso entre segurança e conveniência. Toda vez que a biblioteca upstream atualiza, o hash muda, seu script quebra, e você tem que atualizar o hash. Para um site estável que fixa versões e raramente as atualiza, esta é uma tarefa trimestral. Para um site que usa jquery@latest ou depende de CDNs com auto-atualização, SRI é uma fonte constante de quebras.

Três padrões que tornam a manutenção SRI gerenciável:

• Fixe em versões específicas, não "latest". URL como https://cdn.jsdelivr.net/npm/jquery@3.7.1/dist/jquery.min.js, não jquery@latest. O hash é então estável até você deliberadamente atualizar.
• Use um CDN que publica hashes. cdnjs e jsDelivr ambos publicam o hash SRI para cada arquivo. Atualizar o hash quando você atualiza é uma tarefa de 30 segundos.
• Auto-hospede bibliotecas críticas. Uma vez que você auto-hospeda (o que deveria considerar por razões GDPR de qualquer forma, veja a discussão sobre Google Fonts), SRI se torna irrelevante para esse script. SRI é para casos em que você não pode auto-hospedar. Para analytics, fontes, bibliotecas usadas em uma página, auto-hospedagem é frequentemente a resposta melhor.

Erros comuns

• Esquecer crossorigin="anonymous". O script continua carregando mas não é mais verificado quanto à integridade. A falha SRI silenciosa mais comum.
• Usar SRI em recursos same-origin. Um atacante que pode modificar seu /wp-includes/js/jquery.js também pode modificar o HTML que declara o hash. Use SRI apenas em recursos cross-origin.
• Calcular o hash na versão errada do arquivo. O hash deve corresponder aos bytes exatos que o navegador receberá, incluindo qualquer minificação ou transformação do lado do CDN. Sempre busque da URL real de produção ao calcular.
• Não atualizar o hash em upgrade de biblioteca. Atualize a versão da biblioteca na URL, esqueça de atualizar integrity, o script silenciosamente para de funcionar. Sintomas: uma funcionalidade quebra, o console mostra "Failed to find a valid digest in the integrity attribute".
• Usar SHA-1. SHA-1 é vulnerável a colisões e foi descontinuado para SRI. Use SHA-384 ou SHA-512.
• Tentar usar SRI em um CDN sem CORS. O navegador não pode calcular o hash, então SRI é impossível. Ou o CDN deve habilitar CORS, ou você deve auto-hospedar o arquivo.

SRI e Content Security Policy (CSP)

SRI e CSP são complementares, não redundantes. CSP diz "apenas scripts desta lista de origens estão permitidos a rodar". SRI diz "e esse script deve corresponder a este hash exato". Juntos formam uma abordagem de defesa em profundidade: CSP bloqueia origens desconhecidas; SRI bloqueia adulteração em origens conhecidas. Uma CSP com script-src 'self' https://trusted-cdn.com diz "confiamos em trusted-cdn.com"; adicionar hashes SRI aos seus scripts em trusted-cdn.com estreita essa confiança para versões específicas do arquivo.

A diretiva CSP em rascunho require-sri-for script imporia que todo script cross-origin deve ter um atributo integrity, em nível de navegador. Em 2026 tem suporte limitado mas é a direção para onde o padrão está caminhando.

O que o InspectWP verifica

A seção de Segurança de cada relatório InspectWP inspeciona tags script e stylesheet externas e reporta quais incluem atributos integrity e quais não. SRI ausente em um script de um CDN de terceiros é sinalizado como achado de severidade baixa a média, dependendo do contexto. Uma página de login ou checkout carregando JavaScript externo sem SRI é um aviso de prioridade mais alta. O relatório também sinaliza valores integrity malformados (prefixo de algoritmo errado, base64 inválido) que podem dar uma falsa sensação de proteção enquanto realmente são ignorados pelo navegador. SRI é uma daquelas medidas onde a existência do atributo importa menos do que sua correção; um hash errado é funcionalmente equivalente a nenhum hash porque o navegador ainda rejeita incompatibilidades, mas um atributo crossorigin ausente torna a verificação inteira silenciosa.