Limitar a reescrita de conteúdo do proxy com no-transform e HTTPS

Um proxy que transforma conteúdo pode alterar uma resposta a caminho do navegador: recomprimir uma imagem, reescrever a marcação ou inserir JavaScript de apoio. Uma página que funciona numa rede e adquire marcação desconhecida noutra pode estar a encontrar precisamente esse comportamento do intermediário.

Para um site que opera, o HTTP fornece uma diretiva de resposta explícita:

Cache-Control: no-transform

A RFC 9111 exige que um intermediário que receba esta diretiva de resposta deixe o conteúdo sem transformação, quer implemente ou não uma cache. É relevante para a recompressão de imagens e a injeção de marcação, não apenas para saber se um objeto é armazenado.

Mantenha-a junto da política de cache existente

Se uma resposta já tiver diretivas de cache, acrescente o requisito deliberadamente em vez de descartar o resto da política. Por exemplo, um recurso publicamente armazenável em cache pode ter:

Cache-Control: public, max-age=3600, no-transform

Este exemplo preserva uma política de frescura de uma hora e, ao mesmo tempo, proíbe a transformação do conteúdo. no-transform não implica no-store nem desativa o processamento normal de transferência. Defina-a nas respostas cujo conteúdo original importa, incluindo respostas de imagem separadas quando apropriado.

A diretiva funciona através do cumprimento pelo intermediário. Não impede criptograficamente que um dispositivo de rede ignore a instrução.

Proteja também o transporte

O HTTPS dá ao navegador uma conexão com autenticação e proteção de integridade para o seu par TLS. Um proxy de operador comum que deixa passar tráfego cifrado não pode inserir silenciosamente um script nessa conexão protegida. Mantenha a verificação de certificados ativa; um proxy de inspeção de confiança local que termina TLS é um arranjo diferente.

Sirva a página e os seus recursos dependentes por HTTPS. Redirecione os visitantes HTTP para HTTPS e considere HSTS para uma implementação que o possa suportar de forma consistente. Um simples redirecionamento começa com uma troca HTTP não protegida para um visitante que usou um URL HTTP; uma política HSTS previamente aprendida ou pré-carregada altera essa escolha inicial.

Bloquear um script injetado pode reduzir os seus efeitos visíveis, mas a resposta pode já conter HTML alterado ou URLs de imagens reescritos. Substituir um antigo nome de função, acrescentar um comentário invulgar ou mapear um endereço de injeção histórico não estabelece a integridade do conteúdo para o próximo intermediário.

Ao investigar um relatório, compare a resposta recebida com o conteúdo pretendido da origem e identifique onde o TLS termina. Essa evidência é mais útil do que tratar cada script desconhecido como um defeito no código da própria aplicação do site.