Limita a reescrita de contido do proxy con no-transform e HTTPS

Un proxy que transforma contido pode cambiar unha resposta de camiño ao navegador: recomprimir unha imaxe, reescribir a marcación ou inserir JavaScript de apoio. Unha páxina que funciona nunha rede e recibe marcación descoñecida noutra pode estar atopándose con ese comportamento do intermediario.

Para un sitio que vostede opera, HTTP ofrece unha directiva de resposta explícita:

Cache-Control: no-transform

A RFC 9111 esixe que un intermediario que reciba esta directiva de resposta deixe o contido sen transformar, implemente ou non unha caché. É relevante para a recompresión de imaxes e a inxección de marcación, non só para se un obxecto se almacena.

Mantéñaa xunto coa política de caché existente

Se unha resposta xa ten directivas de caché, engada o requisito de xeito deliberado en lugar de descartar o resto da política. Por exemplo, un recurso almacenábel publicamente podería ter:

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

Este exemplo conserva unha política de frescura dunha hora e á vez prohibe a transformación do contido. no-transform non implica no-store nin desactiva o procesamento ordinario de transferencia. Establézaa nas respostas cuxo contido orixinal importa, incluídas as respostas de imaxe separadas cando corresponda.

A directiva funciona mediante o cumprimento por parte do intermediario. Non impide criptograficamente que un dispositivo de rede ignore a instrución.

Protexa tamén o transporte

HTTPS dálle ao navegador unha conexión con autenticación e protección de integridade cara ao seu par TLS. Un proxy de operador habitual que deixa pasar tráfico cifrado non pode inserir silenciosamente un script nesa conexión protexida. Manteña a verificación de certificados; un proxy de inspección de confianza local que termina TLS é un arranxo distinto.

Sirva a páxina e os seus recursos dependentes por HTTPS. Redirixa os visitantes HTTP a HTTPS e considere HSTS para un despregamento que poida soportalo de forma constante. Unha redirección por si soa comeza cun intercambio HTTP non protexido para un visitante que usou un URL HTTP; unha política HSTS aprendida previamente ou precargada cambia esa elección inicial.

Bloquear un script inxectado pode reducir os seus efectos visibles, pero a resposta pode conter xa HTML modificado ou URL de imaxes reescritas. Substituír un nome de función antigo, engadir un comentario inusual ou mapear un enderezo de inxección histórico non establece a integridade do contido para o seguinte intermediario.

Ao investigar un informe, compare a resposta recibida co contido previsto da orixe e identifique onde remata TLS. Esa evidencia é máis útil que tratar cada script descoñecido como un fallo no código da propia aplicación do sitio.