Limit Proxy Content Rewriting with no-transform and HTTPS

A transforming proxy can change a response on its way to the browser: recompress an image, rewrite markup or insert supporting JavaScript. A page that works on one network and acquires unfamiliar markup on another may be encountering that intermediary behavior.

For a site you operate, HTTP provides an explicit response directive:

Cache-Control: no-transform

RFC 9111 requires an intermediary receiving this response directive to leave the content untransformed, whether or not that intermediary implements a cache. It is relevant to image recompression and markup injection, not just to whether an object gets stored.

Keep it with the existing cache policy

If a response already has cache directives, add the requirement deliberately rather than discarding the rest of the policy. For example, a publicly cacheable asset might have:

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

This example preserves a one-hour freshness policy while disallowing content transformation. no-transform does not imply no-store or disable ordinary transfer processing. Set it on the responses whose original content matters, including separate image responses where appropriate.

The directive works through an intermediary’s compliance. It does not cryptographically prevent a network device from ignoring the instruction.

Protect the transport as well

HTTPS gives the browser a connection with authentication and integrity protection to its TLS peer. An ordinary carrier proxy passing encrypted traffic cannot silently insert a script into that protected connection. Keep certificate verification in place; a locally trusted inspection proxy that terminates TLS is a different arrangement.

Serve the page and its dependent resources over HTTPS. Redirect HTTP visitors to HTTPS, and consider HSTS for a deployment that can consistently support it. A redirect alone starts with an unprotected HTTP exchange for a visitor who used an HTTP URL; a previously learned or preloaded HSTS policy changes that initial choice.

Blocking an injected script can reduce its visible effects, but the response may already contain changed HTML or rewritten image URLs. Replacing one old function name, adding an unusual comment or mapping a historical injection address does not establish content integrity for the next intermediary.

When investigating a report, compare the received response with the origin’s intended content and identify where TLS terminates. That evidence is more useful than treating every unfamiliar script as a bug in the site’s own application code.