Content Security Policy, Subresource Integrity e telemetria de saída contra ataques à cadeia de suprimentos no navegador

O risco de cadeia de suprimentos no navegador tem múltiplos pontos de controle

Um navegador pode executar código montado a partir de muitas fontes. O documento inicial, os scripts externos, os scripts inline, os frames, os estilos e as respostas de interfaces de programação de aplicações se combinam em uma única experiência do usuário. Uma fraqueza em qualquer caminho de entrega ou autorização pode alterar o que o navegador executa e para onde os dados viajam.

Nenhum controle isolado de navegador observa o problema inteiro. A Content Security Policy restringe classes de comportamento de recurso e de execução. A Subresource Integrity verifica o conteúdo de recursos externos selecionados antes da execução. A telemetria de saída registra scripts, destinos e comportamento de página que de fato aparecem. Cada controle responde a uma pergunta diferente.

Usá-los em conjunto cria um modelo mais forte: definir o que deve ser permitido, vincular conteúdo externo estável onde for prático, observar o que acontece e investigar a deriva. Usar um sozinho deixa lacunas previsíveis.

A Content Security Policy define o comportamento permitido no navegador

A Content Security Policy é entregue por meio de um cabeçalho de resposta do Hypertext Transfer Protocol ou, em casos restritos, pela marcação do documento. Ela fornece diretivas que dizem ao navegador quais fontes e comportamentos são permitidos para scripts, conexões, frames, formulários, estilos, imagens e outros tipos de recurso. O OWASP Secure Headers Project fornece uma referência técnica adicional sobre o comportamento de cabeçalhos de resposta e sua implantação.

Uma política forte começa com um padrão restritivo e adiciona as menores fontes necessárias. A política de script deve evitar curingas amplos e permissões inseguras de execução. A política de conexão deve limitar fetch, requisições assíncronas, event streams e conexões de navegador relacionadas. As diretivas de frame e formulário restringem o conteúdo incorporado e os destinos de envio. O carregamento de objetos muitas vezes pode ser desabilitado.

Nonces ou hashes podem autorizar scripts inline específicos sem permitir todo bloco inline. Um nonce único deve ser imprevisível e gerado por resposta. A autorização baseada em hash pode servir para conteúdo inline estável. As allowlists de host são mais fáceis de implantar, mas podem ser mais fracas quando um host permitido pode servir conteúdo controlado por um atacante.

A implantação apenas em modo de relato permite que os times observem as violações antes da imposição. Ela é útil para descoberta e ajuste, mas não bloqueia o comportamento proibido. Uma implantação madura move as diretivas justificadas para a imposição e mantém o relato para visibilidade.

A Content Security Policy pode estar presente e ainda assim ser fraca

A existência de um cabeçalho não prova proteção significativa. Uma política pode permitir toda fonte de rede, permitir execução inline insegura, omitir diretivas críticas ou definir um padrão estreito ao mesmo tempo em que o sobrescreve com regras amplas de script e conexão. Políticas duplicadas ou conflitantes também podem produzir um comportamento que os operadores interpretam mal.

A avaliação da política deve, portanto, inspecionar a semântica das diretivas. A execução de script tem um modelo de fonte restritivo? Os formulários são restringidos? Os frames podem carregar de origens inesperadas? As conexões de saída são mais amplas do que as integrações documentadas da aplicação? Os endpoints de relato estão configurados e funcionando?

Os relatórios de violação também precisam de contexto. Uma extensão de navegador, uma página desatualizada, uma tentativa maliciosa ou um comportamento legítimo da aplicação podem gerar uma violação. Os relatórios são evidência de comportamento bloqueado ou em modo de relato, não ataques automaticamente confirmados. A agregação deve preservar a página, a diretiva, a categoria de endereço bloqueado e o momento sem coletar dados sensíveis do documento.

A Subresource Integrity vincula um recurso ao conteúdo esperado

A Subresource Integrity permite que a marcação declare um ou mais digests criptográficos para um recurso. O navegador busca o recurso e verifica o corpo contra um digest aceito antes da execução ou aplicação. Isso é valioso quando se espera que um script externo permaneça estável e o dono da página possa atualizar o digest por meio de um lançamento controlado.

O atributo de integridade deve ser combinado com o comportamento correto de cross-origin onde exigido. Os algoritmos e digests precisam ser atuais e gerados a partir dos bytes exatos entregues. Um recurso alterado deixará de carregar até que o digest esperado da página seja atualizado.

Esse comportamento de falha é tanto a força quanto o custo operacional do controle. Se um recurso externo muda com frequência sem fixação de versão, a verificação de integridade pode quebrar a aplicação. Os times podem responder omitindo o controle, atualizando os digests automaticamente ou autorizando versões amplas demais. Cada atalho reduz o valor de segurança.

A Subresource Integrity também cobre apenas os recursos referenciados com o mecanismo. Ela não inventaria todo script carregado dinamicamente, não restringe todas as conexões de saída nem protege a marcação da página que declara o digest. Uma página de primeira parte comprometida pode substituir tanto o endereço do recurso quanto seu fingerprint esperado.

A telemetria de saída observa o comportamento entregue e executado

A telemetria de saída registra o que o navegador ou a borda de fato observa: fontes de script, fingerprints de conteúdo inline, estado de autorização, mudanças de conteúdo, destinos cross-origin, destinos de formulário, frames e postura de resposta. Ela pode revelar um script alterado mesmo quando a Content Security Policy permite a fonte, ou um novo destino escondido dentro de uma política de conexão amplamente permitida.

A observação apoia o inventário e a investigação. O momento de primeira e última observação mostra a persistência. A comparação com a linha de base revela a mudança. A atribuição de página identifica onde o recurso apareceu. As contagens de destino mostram se o comportamento é isolado ou recorrente. O ciclo de vida do alerta registra o reconhecimento, o risco aceito, a reabertura e a resolução técnica.

A telemetria não é prevenção automática. Um agente de navegador que reporta uma requisição geralmente observa um comportamento que o navegador já tentou ou concluiu. Marcar um destino como não permitido em um inventário não bloqueia retroativamente a chamada de rede. A imposição pertence à Content Security Policy, ao design da aplicação, ao roteamento ou a outro controle preventivo.

Essa fronteira deve ser visível na interface. Termos como permitir e bloquear podem ser enganosos se apenas mudam o estado de triagem. Os operadores precisam saber se uma ação atualiza uma classificação de inventário ou muda o comportamento de runtime.

Como os três controles se complementam

A sobreposição é intencional. A Content Security Policy fornece imposição no navegador, mas pode ser configurada de forma ampla. A Subresource Integrity fornece verificação em nível de byte, mas apenas para recursos declarados. A telemetria fornece evidência de inventário e de deriva, mas pode observar o comportamento depois que ele ocorre. Juntos, eles transformam a confiança em um estado restrito e monitorado.

Uma sequência de implantação segura

1. Inventarie o comportamento atual. Observe scripts, frames, formulários e destinos em estados de página representativos.
2. Atribua a propriedade. Identifique por que cada recurso existe e quem aprova as mudanças.
3. Remova as fontes desnecessárias. Um conjunto menor de dependências de navegador é mais fácil de restringir e revisar.
4. Crie uma política em modo de relato. Comece a partir de um alvo restritivo, colete as violações e classifique os requisitos legítimos.
5. Fixe os scripts externos estáveis. Adicione Subresource Integrity onde o ciclo de vida do recurso suporta versionamento controlado.
6. Imponha a política por sensibilidade da página. Priorize os fluxos de autenticação, pagamento, conta e administração.
7. Estabeleça uma linha de base do conteúdo aprovado. Registre os fingerprints de script e o estado da superfície de resposta após a revisão.
8. Alerte sobre a deriva. Investigue novos scripts, conteúdo alterado, destinos, frames, formulários e cabeçalhos mais fracos.
9. Teste o comportamento de falha. Confirme que um digest ruim impede a execução, que um destino proibido é restringido e que a telemetria cria evidência utilizável.
10. Revise continuamente. Remova as fontes expiradas, rotacione as linhas de base aprovadas após a investigação e monitore a saúde da coleta.

Um cenário controlado de incidente

Considere um script autorizado em uma página de checkout. Sua fonte permanece na allowlist da Content Security Policy, mas o conteúdo entregue muda. A página não usa Subresource Integrity porque o script historicamente mudava sem endereços versionados.

A Content Security Policy permite o script porque a fonte é permitida. A telemetria de saída detecta que o digest atual difere da linha de base aprovada. As observações do navegador também reportam um novo destino de formulário cross-origin. Essas duas mudanças elevam a prioridade da investigação.

O time confirma que não houve lançamento aprovado, remove a referência ao script, restringe os destinos de formulário por meio da política, restaura a resposta anterior e aciona os procedimentos de incidente. Uma observação bem-sucedida posterior mostra a linha de base antiga e nenhum destino de formulário externo, permitindo que os achados técnicos se resolvam. O time então introduz um recurso versionado e a Subresource Integrity para que futuras mudanças de bytes não aprovadas falhem antes da execução.

O cenário mostra por que a allowlist de fonte sozinha foi insuficiente, por que a telemetria sozinha não impediu a primeira tentativa e por que a verificação de bytes poderia fortalecer o próximo design.

Métricas para a qualidade do controle no navegador

Métricas úteis incluem páginas observadas, atualidade da coleta, scripts totais e autorizados, scripts autorizados alterados, novos recursos, destinos externos, envios de formulário a origens externas, achados de Content Security Policy, tendências de violação, cobertura de Subresource Integrity e tempo médio até a disposição.

Inclua sempre os denominadores. Sete scripts com controles de integridade só é significativo ao lado da contagem total de scripts elegíveis. Zero scripts alterados só é significativo quando as páginas monitoradas têm observações recentes. Uma contagem alta de violações pode refletir um novo ataque, uma política em modo de relato estrita demais, um lançamento de aplicação quebrado ou um único cliente ruidoso.

As pontuações de postura podem resumir a direção, mas o cálculo e as entradas ausentes precisam ser explicáveis. Se a telemetria de navegador estiver indisponível, a pontuação não deve tratar silenciosamente o módulo como limpo.

Lista de verificação operacional

• Use um alvo restritivo de Content Security Policy em vez de copiar o comportamento observado para uma allowlist ampla.
• Prefira nonces ou hashes para a execução inline justificada.
• Restrinja os destinos de conexão, frame e formulário, não apenas os scripts.
• Use Subresource Integrity para recursos externos estáveis com versionamento controlado.
• Inventarie scripts dinâmicos e inline além das tags externas estáticas.
• Mantenha a autorização separada da observação e preserve as linhas de base aprovadas.
• Não descreva a classificação de inventário como bloqueio de rede.
• Teste o comportamento de política, digest, alerta e recuperação em um ambiente controlado.
• Mostre explicitamente a coleta desatualizada ou indisponível.
• Revise o risco aceito e as fontes amplas de política em cadência.

Limitações

A Content Security Policy pode ser difícil de implantar em aplicações com código inline extenso ou carregamento dinâmico de recursos. A Subresource Integrity pode interromper recursos que mudam sem versionamento estável. A telemetria de navegador pode ser incompleta por causa de controles de privacidade, agentes bloqueados, cache, caminhos de execução ou falha de rede.

Esses controles não protegem um navegador comprometido, toda extensão, o pipeline de build subjacente ou a lógica insegura da aplicação. Eles também não determinam se um destino observado é legítimo sem propriedade e contexto de negócio.

Conclusão

A defesa da cadeia de suprimentos no navegador precisa tanto de uma regra quanto de um registro. A Content Security Policy define onde e como o navegador pode agir. A Subresource Integrity vincula os recursos selecionados ao conteúdo revisado. A telemetria de saída registra os scripts, os destinos e as mudanças que aparecem no comportamento real da página.

Nenhum é completo sozinho. Usados em conjunto, eles tornam a confiança no navegador mais estreita, observável e revisável, ao mesmo tempo em que dão aos times a evidência para ir da mudança inesperada à melhoria preventiva.

Onde a Vorpcel se encaixa

O Vorpcel Outbound Control avalia a Content Security Policy e a postura de resposta, inventaria scripts e linhas de base aprovadas, observa os destinos do navegador e detecta a deriva da superfície de resposta. Sua fronteira de imposição permanece explícita: os cabeçalhos do navegador restringem o comportamento, enquanto a telemetria e os registros de triagem explicam o que foi observado e o que exige investigação.