Limitar la reescritura de contenido del proxy con no-transform y HTTPS

Un proxy que transforma contenido puede cambiar una respuesta de camino al navegador: recomprimir una imagen, reescribir el marcado o insertar JavaScript de apoyo. Una página que funciona en una red y recibe marcado desconocido en otra puede estar encontrándose con ese comportamiento del intermediario.

Para un sitio que usted opera, HTTP ofrece una directiva de respuesta explícita:

Cache-Control: no-transform

La RFC 9111 exige que un intermediario que reciba esta directiva de respuesta deje el contenido sin transformar, implemente o no una caché. Es relevante para la recompresión de imágenes y la inyección de marcado, no solo para si un objeto se almacena.

Manténgala junto con la política de caché existente

Si una respuesta ya tiene directivas de caché, añada el requisito de forma deliberada en lugar de descartar el resto de la política. Por ejemplo, un recurso almacenable públicamente podría tener:

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

Este ejemplo conserva una política de frescura de una hora y a la vez prohíbe la transformación del contenido. no-transform no implica no-store ni desactiva el procesamiento ordinario de transferencia. Establézcala en las respuestas cuyo contenido original importa, incluidas las respuestas de imagen separadas cuando corresponda.

La directiva funciona mediante el cumplimiento por parte del intermediario. No impide criptográficamente que un dispositivo de red ignore la instrucción.

Proteja también el transporte

HTTPS da al navegador una conexión con autenticación y protección de integridad hacia su par TLS. Un proxy de operador habitual que deja pasar tráfico cifrado no puede insertar silenciosamente un script en esa conexión protegida. Mantenga la verificación de certificados; un proxy de inspección de confianza local que termina TLS es un arreglo distinto.

Sirva la página y sus recursos dependientes por HTTPS. Redirija a los visitantes HTTP hacia HTTPS y considere HSTS para un despliegue que pueda soportarlo de forma constante. Una redirección por sí sola comienza con un intercambio HTTP no protegido para un visitante que usó una URL HTTP; una política HSTS aprendida previamente o precargada cambia esa elección inicial.

Bloquear un script inyectado puede reducir sus efectos visibles, pero la respuesta podría contener ya HTML modificado o URL de imágenes reescritas. Sustituir un nombre de función antiguo, añadir un comentario inusual o mapear una dirección de inyección histórica no establece la integridad del contenido para el siguiente intermediario.

Al investigar un informe, compare la respuesta recibida con el contenido previsto del origen e identifique dónde termina TLS. Esa evidencia es más útil que tratar cada script desconocido como un fallo del código de la propia aplicación del sitio.